Codex domyka tanie zadania mechaniczne, Claude Code prowadzi zmianę, którą trzeba najpierw zaplanować. Dwa scenariusze, koszt z cennika i pięć zabezpieczeń przed startem.
Wprowadzenie
Codex kontra Claude Code to nie wybór między dobrym i złym narzędziem, a podział zadań. Codex domyka tanie zadania mechaniczne, Claude Code prowadzi zmianę, w której trzeba najpierw wymyślić plan. Poniżej pokazuję, po czym je rozdzielam i ile to kosztuje.
Pięć rzeczy, które biorę pod uwagę:
- dwa style pracy i różnicę w domyślnych uprawnieniach,
- co realnie robi tryb
--yoloi kiedy jest zbyt ryzykowny, - koszt dwóch zadań policzony z cennika z 25 października 2026,
- komendy startowe dla obu narzędzi,
- jak sprawdzić realny koszt, gdy raport narzędzia zaniża zużycie.
Liczby w tabeli kosztów są syntetyczne. Policzyłem je z cenników OpenAI i Anthropic tego samego dnia, przy założeniach zużycia, które podaję razem z tabelą. Nie uruchamiałem obu narzędzi na tym samym zadaniu, bo karta wpisu tego zabrania, a wyniki cudzych testów mnie nie interesują.
Codex kontra Claude Code: dwa style pracy
Codex i Claude Code to dwa agenty terminalowe od dwóch różnych firm. Codex jest częścią planów ChatGPT, Claude Code częścią planów Claude. Oba czytają repozytorium, edytują pliki i uruchamiają komendy, więc różnica nie leży w tym, co potrafią, a w tym, jak domyślnie traktują twoją zgodę.
Codex ma dwa pokrętła uprawnień. Flaga --sandbox przyjmuje wartości read-only, workspace-write i danger-full-access, a --ask-for-approval wartości on-request i never. Dokumentacja OpenAI zaleca na start --sandbox workspace-write --ask-for-approval on-request, czyli zapis tylko w katalogu roboczym i pytanie o zgodę wtedy, gdy agent uzna, że jej potrzebuje.
Claude Code stoi na trybach uprawnień. Sesja interaktywna startuje w trybie auto, w którym agent działa bez pytania o każdą komendę, a tryb ręczny zaczyna od uprawnień tylko do czytania. Sandbox dla komend bash włącza się osobno przez /sandbox, z izolacją systemu plików i sieci.
Trzecia różnica jest praktyczna. Codex ma osobną komendę codex review, która przegląda niezacommitowane zmiany, diff względem gałęzi albo wskazany commit. Claude Code ma tryb planowania --permission-mode plan, w którym najpierw powstaje plan, a pliki czekają.
Tryb --yolo: co robi i kiedy ma sens
Flaga --yolo w Codex to alias --dangerously-bypass-approvals-and-sandbox. Dokumentacja opisuje ją bez ozdobników: każda komenda leci bez zatwierdzeń i bez sandboxa, a użycie ma sens tylko w środowisku utwardzonym z zewnątrz.
Claude Code ma odpowiednik pod nazwą --dangerously-skip-permissions, równoważny --permission-mode bypassPermissions. Nazwa mówi wszystko: znika pytanie o zgodę, zostaje zaufanie do agenta.
Ryzyko nie jest teoretyczne. Bez sandboxa agent sięga do sieci i do całego dysku zalogowanego użytkownika, więc plik klienta w katalogu domowym i klucz API w zmiennych środowiskowych są w zasięgu jednej komendy. Gałąź w gicie chroni kod, ale nie chroni danych, które nie są w gicie.
Wariant pośredni istnieje i rzadko się o nim mówi. Codex ma flagę --approve-for-me, alias --not-so-yolo, która zostawia sandbox workspace-write i automatyczny przegląd zgód. To jest tryb, którego używam, gdy chcę mniej klikania bez oddawania kontroli.
Tryb --yolo ma sens w czterech warunkach naraz: kontener bez danych klienta, gałąź jednorazowa, testy dające wynik w kilka minut i brak sekretów w środowisku. Poza tym zestawem nie używam go wcale.
Koszt jednego zadania: dwa scenariusze z tego samego dnia
Koszt zadania liczę z cennika tokenów, bo to jedyna liczba, którą mogę sprawdzić u źródła. Cennik OpenAI z 25 października 2026 podaje dla GPT-6.1 Sol 2,00 USD za 1 mln tokenów wejściowych i 10,00 USD za 1 mln wyjściowych. Anthropic podaje dla Opus 5.5 4,00 i 20,00 USD, a dla Sonnet 5.5 2,00 i 10,00 USD.
Zużycie tokenów przyjąłem własne, bo nie mierzyłem obu narzędzi na tych zadaniach. Scenariusz A to zmiana nazwy parametru w 30 plikach rozszerzenia pyRevit, bez decyzji projektowej. Scenariusz B to jedna funkcja przechodząca przez sześć plików, z migracją formatu i testami.
| Scenariusz | Wejście | W tym z cache | Wyjście | Codex, GPT-6.1 Sol | Claude Opus 5.5 |
|---|---|---|---|---|---|
| A: 30 plików, jedna zmiana | 1 200 000 | 85% | 25 000 | 0,71 USD | 1,42 USD |
| B: zmiana wieloetapowa | 3 500 000 | 80% | 120 000 | 2,88 USD | 5,76 USD |
Różnica bierze się z cennika, nie z jakości odpowiedzi. Opus 5.5 kosztuje dwa razy więcej za token wejściowy i wyjściowy niż GPT-6.1 Sol, więc te same zadania wychodzą dwa razy drożej. Sonnet 5.5 ma cennik równy GPT-6.1 Sol, więc trzecia kolumna nic by tu nie zmieniła.
Abonament zmienia obraz. ChatGPT Plus kosztuje 20 USD miesięcznie, Pro od 100 USD, a plany Pro występują w wersjach za 100, 200 i 500 USD. Claude Pro kosztuje 20 USD, Max od 100 USD, z wyborem pięciu albo dwudziestu razy większego zużycia niż Pro na pięciogodzinną sesję.
Przy dwudziestu zadaniach A i ośmiu B w miesiącu klucz API wystawiłby 37,24 USD na GPT-6.1 Sol i 74,48 USD na Opus 5.5. Plan Plus za 20 USD wygrywa więc z kluczem przy takim wolumenie. Strona Codexa mówi jednak wprost, że ceny tokenów API nie służą do szacowania zadań w abonamencie, bo plan rozlicza się limitem, nie rachunkiem.
Kiedy Codex: 30 plików, jedna mechaniczna zmiana, wynik sprawdzalny testem
Zadanie mechaniczne ma trzy cechy: powtarzalna zmiana w wielu plikach, brak decyzji projektowej i wynik, który sprawdzi test albo git diff. Agent nie musi wtedy nic rozumieć, wystarczy, że wykona polecenie dokładnie.
Przykład z mojej pracy to zmiana nazwy parametru w rozszerzeniu pyRevit. Trzydzieści plików, jedna nazwa, test, który po zmianie ma dalej przechodzić. Cztery komendy wystarczą.
git switch -c porzadki/nazwa-parametru
codex exec --sandbox workspace-write --ask-for-approval never "zmien nazwe parametru WysokoscSciany na WysokoscKondygnacji w plikach .py i uruchom pytest"
git diff --stat
codex review --uncommittedPierwsza komenda tworzy gałąź, druga uruchamia Codex bez interfejsu, trzecia pokazuje skalę zmiany, czwarta robi przegląd przed commitem. Ta kolejność waży więcej niż wybór narzędzia.
Plan Plus obejmuje od 15 do 160 lokalnych wiadomości na pięć godzin na modelu GPT-6.1 Sol, zależnie od rozmiaru zadania. Zmiana w 30 plikach mieści się w tym zakresie bez sięgania po wyższy plan. Szerszy opis Codexa w pracy inżyniera zostawiłem w osobnym wpisie Codex do dokumentacji Excela i pracy inżyniera.
Kiedy Claude Code: wieloetapowa zmiana, zależności, brak oczywistego wyniku
Zmiana wieloetapowa zaczyna się od pytania, którego nie ma w treści zadania: w której warstwie zmienić model danych i co zrobić ze starym formatem plików. Odpowiedź zależy od reszty repozytorium, więc agent musi najpierw przeczytać, a potem zaproponować kolejność.
Claude Code ma do tego tryb planowania uruchamiany flagą --permission-mode plan. Sesja czyta repozytorium i przedstawia plan, a pliki zostają nietknięte do momentu zatwierdzenia. Dopiero potem wchodzi implementacja.
W scenariuszu B plan jest tańszy od błędu. Jeden przebieg z planem na Sonnecie 5.5 i implementacją na Opusie 5.5 dzieli koszt inaczej niż jedno przejście drogim modelem od początku do końca. Claude Code pobiera zużycie z jednej puli, wspólnej dla czatu i terminala, więc planowanie zjada ten sam limit co rozmowa w przeglądarce.
Claude Code da się też uruchomić na tanim backendzie przez OpenRouter i ten wariant opisałem w wpisie Claude za półdarmo. Nie zastępuje planu, ale obniża cenę eksperymentu.
Workflow łączony: plan w jednym narzędziu, wykonanie w drugim, weryfikacja w trzecim kroku
Plan i wykonanie mogą stać w dwóch różnych narzędziach, bo pierwszy krok kończy się tekstem, a drugi diffem. Trzy kroki, dwie komendy i jedna decyzja, którą podejmuję sam.
- Plan w Claude Code:
claude --permission-mode planz opisem zmiany. Wynik to lista plików i kolejność prac, którą zapisuję w pliku obok repozytorium. - Wykonanie w Codex:
codex execz tym planem w treści zadania i sandboxemworkspace-write. - Weryfikacja:
codex review --uncommitted, potem testy i własne czytanie diffa.
Plan z pierwszego kroku wklejam do drugiego jako treść zadania, bo agent bez planu wymyśla własny. Trzeci krok zostaje przy mnie, bo przegląd robiony przez to samo narzędzie, które pisało kod, ma tę samą ślepotę. Podział modeli na zadania opisałem szerzej we wpisie o routingu zadań.
Zabezpieczenia: gałąź, git, testy, limit zakresu, katalog roboczy
Pięć zabezpieczeń wprowadzam przed pierwszym uruchomieniem, nie po pierwszym incydencie. Każde z nich kosztuje minutę, a bez nich cofnięcie złej zmiany zajmuje godzinę.
- Gałąź:
git switch -cprzed startem, agent nigdy nie pracuje na głównej gałęzi. - Czysty git:
git statusprzed uruchomieniem, bo w brudnym drzewie nie odróżnię zmian agenta od własnych. - Testy przed zmianą: uruchamiam je na starym kodzie, żeby wiedzieć, które padały już wcześniej.
- Limit zakresu: lista plików w treści zadania, bo agent poprawiający przy okazji 40 innych plików jest tańszy do cofnięcia niż do przeglądu.
- Katalog roboczy: start w katalogu repozytorium. Claude Code pyta o zgodę przed wyjściem poza katalog startowy, a Codex ogranicza zapis sandboxem. Oba mechanizmy przestają działać, gdy agent startuje w katalogu domowym.
Jak zmierzyć realny koszt, gdy raport narzędzia kłamie
Raport narzędzia liczy to, co widzi, a nie to, co zapłaciłeś. W sesji Codexa komenda /status pokazuje pozostały limit, a dashboard zużycia pokazuje go po fakcie. Fakturę wystawia dostawca i ona jest jedyną liczbą, która się liczy.
Po każdym zadaniu zapisuję trzy liczby: tokeny wejściowe i wyjściowe z raportu sesji, czas od startu do zielonych testów oraz liczbę plików w diffie. Iloczyn pierwszych dwóch i ceny z cennika daje koszt, który da się porównać z innym narzędziem. Czas liczę osobno, bo limit pięciogodzinny w abonamencie kosztuje nie dolary, a czekanie na reset.
Rozjazd między raportem a fakturą bierze się najczęściej z cache. Tokeny czytane z cache kosztują w cenniku OpenAI 0,10 USD za 1 mln, a w cenniku Anthropica 0,20 USD za 1 mln dla Opus 5.5. Zadanie z dużym udziałem cache wygląda więc w raporcie na droższe, niż wyszło. Ten sam problem opisałem w wpisie Pomiar kosztu zadania, a cennik abonamentów zebrałem w Maksimum z subskrypcji.
Kiedy to nie zadziała
Trzy przypadki psują cały podział, niezależnie od tego, które narzędzie wybierzesz. Lepiej znać je przed startem niż po.
Zadanie bez testów nie daje sygnału poprawności. Oba narzędzia zwrócą diff, którego nikt nie przeczyta w całości, a przegląd robiony przez model oceni styl, nie zachowanie programu.
Repozytorium z sekretami w środowisku znosi sens sandboxa. Jeśli w zmiennych leży klucz produkcyjny, agent z uprawnieniami do sieci może go użyć, a flaga --yolo tylko skraca drogę.
Długie zadanie w planie abonamentowym zjada limit pięciogodzinny. Kosztem nie są wtedy dolary, a przerwa do resetu, której nie da się skrócić dopłatą w każdym planie.
Źródła
Jak powstał ten materiał: koszty policzyłem z cenników, nie z pomiaru przebiegu, bo karta wpisu zabrania uruchamiania realnych zadań. Nie testowałem obu narzędzi na tym samym repozytorium i nie powołuję się na cudze benchmarki.
Cennik i dokumentacja OpenAI, sprawdzone 25 października 2026: cennik Codexa, dokumentacja CLI Codexa, cennik API OpenAI.
Cennik i dokumentacja Anthropic, sprawdzone tego samego dnia: cennik planów Claude, dokumentacja CLI Claude Code, bezpieczeństwo Claude Code, cennik API Anthropic.
Liczby w tabeli kosztów pochodzą z arkusza koszty-syntetyczne.json w katalogu wpisu. Skrypt liczący i kontrola poleceń startowych względem dokumentacji leżą w _skrypty/.
Ujawnienie AI: Treść tego artykułu przygotował agent AI pracujący na mojej instalacji Hermesa, na podstawie cenników i dokumentacji sprawdzonych 25 października 2026. Tekst przechodzę i zatwierdzam przed publikacją.
