Claude Code i Codex przez noc: konfiguracja /goal

Informacje o korzystaniu z Ailoot znajdziesz w dokumentacji.

Czym jest /goal i dlaczego pojawiło się w 2026 roku?#

Scenariusz, który wszyscy znaliśmy przed kwietniem 2026 roku: zlecam Claude’owi zadanie: „przenieś projekt z Pydantic v1 na v2”. Agent zaczyna, zatrzymuje się po 30 sekundach, sprawdzam, co zrobił, piszę „kontynuuj”, agent wykonuje następny krok, zatrzymuje się, a ja znów piszę „kontynuuj”. Przy dużej migracji oznacza to 200–300 ręcznych poleceń „kontynuuj”. W praktyce pilnuję agenta zamiast równolegle pisać inny kod.

Z analizy OpenAI wynikało, że problemem nie była „głupota” modelu, lecz architektura pętli. Model nie wiedział, kiedy się zatrzymać, więc przy każdej turze naciskał hamulec. Jeśli podasz mu kryterium ukończenia, sam podejmie decyzję.

Tak powstało /goal — mechanizm wbudowany w harness, a nie w model.

Wypowiedź padła na konferencji Code with Claude w Londynie, 19–20 maja 2026 roku. Opisuje to, co faktycznie wydarzyło się w miesiącu po premierze /goal w obu narzędziach.

Jak skonfigurować tryb Goal w Claude Code?#

Minimalny przykład z oficjalnej dokumentacji Anthropic:

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

To polecenie uruchamia agenta w tle z jednym celem. Claude wyszukuje PR-y, porównuje je z CHANGELOG.md, dodaje brakujące wpisy i kończy pracę po spełnieniu kryterium.

W trybie interaktywnym wystarczy wpisać /goal, a następnie warunek:

/goal all pytest tests pass and mypy strict reports zero errors

Co Claude robi dalej:

• Po każdej turze osobny szybki model (domyślnie Haiku) otrzymuje aktualny warunek i historię rozmowy
• Model odpowiada „tak” lub „nie” i podaje krótkie uzasadnienie
• Jeśli odpowiedź brzmi „nie”, Claude automatycznie wykonuje kolejną turę, nie oddając Ci kontroli
• Jeśli odpowiedź brzmi „tak”, cel zostaje wyczyszczony, a kontrola wraca do Ciebie

Oto twarde ograniczenia, o których dowiesz się dopiero, gdy na nie trafisz:

• /goal działa tylko w katalogach roboczych, dla których zaakceptowano okno dialogowe zaufania. Na nowym komputerze polecenie nie zadziała, jeśli Claude nie zapamiętał jeszcze tego katalogu
• W środowiskach firmowych z ustawieniem disableAllHooks lub allowManagedHooksOnly polecenie jest niedostępne
• Warunek może mieć maksymalnie 4 000 znaków
• W jednej sesji może być aktywny tylko jeden cel. Nowe /goal resetuje poprzedni
• Przy użyciu --resume warunek zostaje zachowany, ale liczniki tur, czasu i tokenów są resetowane

Polecenia sterujące:

• /goal bez argumentu — pokaż bieżący stan
• /goal clear (lub stop, off, reset, none, cancel) — wyczyść cel

Według Anthropic koszt ewaluatora jest „zwykle nieistotny w porównaniu z kosztem głównej tury”. Haiku ocenia kryterium i tekst rozmowy, nie wywołując narzędzi, więc sprawdzenie jest tanie; kosztowne są tury głównego modelu.

Jak skonfigurować /goal w Codex CLI?#

Polecenie wygląda tak samo jak w Claude:

codex
> /goal all vitest tests pass and there are no eslint errors

Codex oferuje więcej poleceń do zarządzania celem:

Główna różnica w porównaniu z Claude polega na tym, że Codex sam sprawdza, czy „skończył”, zamiast korzystać z osobnego modelu. Po każdej turze Codex automatycznie wstawia do kontekstu szablon continuation.md z repozytorium openai/codex. Dosłowne tłumaczenie:

„Kontynuuj pracę nad aktywnym celem wątku. Nie powtarzaj wykonanej już pracy. Wybierz następne konkretne działanie, które przybliża do celu. Oznacz cel jako osiągnięty tylko wtedy, gdy audyt potwierdzi, że faktycznie został osiągnięty i nie pozostała żadna wymagana praca.”

Gdy liczba tokenów zbliża się do limitu, wstawiany jest drugi szablon — budget_limit.md:

„Cel osiągnął limit tokenów. Nie rozpoczynaj znaczących nowych prac. Zakończ tę turę jak najszybciej: podsumuj przydatne postępy, wskaż pozostałe prace i blokady oraz jasno przedstaw użytkownikowi następny krok.”

Logika jest taka sama: „nie kłam na temat tego, co zostało zrobione”. Kontynuacja jest wymagana tylko wtedy, gdy cel rzeczywiście nie został osiągnięty. budget_limit wymaga zatrzymania, ale uczciwego opisania tego, co pozostało.

W przeciwieństwie do Claude, Codex wiąże cel z wątkiem, a nie z sesją. Możesz zamknąć terminal wieczorem i ponownie otworzyć go rano, a /goal resume podejmie pracę nad tym samym celem i z tymi samymi faktami w pamięci. Przydaje się to przy dzieleniu pracy na części zgodnie z własnym harmonogramem.

Czym różni się /goal w Claude Code od /goal w Codex?#

To najczęściej pomijana różnica w porównaniach, przyjrzyjmy się jej więc szczegółowo.

Różnica koncepcyjna polega na tym, że Claude traktuje pętlę jako umowę dotyczącą jakości (zewnętrzny ewaluator), a Codex jako mechanizm wykonawczy (agent zarządza sobą).

W praktyce: jeśli chcesz, aby kryterium ukończenia oceniała bezstronna instancja, wybierz Claude. Jeśli agent ma móc sprawdzać pliki i dzienniki podczas oceny, wybierz Codex.

Więcej informacji o samych narzędziach znajdziesz w przewodniku Codex kontra Claude Code.

Rzeczywisty przykład: migracja z Pydantic v1 do v2 w 31 godzin#

Zadanie sformułowano następująco: „przenieś z Pydantic v1 na v2, wszystkie testy pytest muszą przechodzić, a mypy strict musi zgłaszać zero błędów”.

Przebieg:

• Sesja 1 (8 godzin) — Codex przeanalizował importy, przepisał deklaracje BaseModel i skonfigurował mypy
• Sesja 2 (10 godzin) — przepisał walidatory i zepsuł około 200 testów
• Sesja 3 (7 godzin) — naprawił testy i znalazł zależności cykliczne
• Sesja 4 (6 godzin) — rozwiązał pozostałe błędy mypy i regresje

Koszt tokenów:

„Łączny czas pracy: około 31 godzin w czterech sesjach. Łączny koszt tokenów Codex według stawek gpt-5.3-codex: około $44.”

Największą część kosztów stanowią tokeny wyjściowe gpt-5.3-codex, których stawka wynosi $14 za milion. Oznacza to, że 31 godzin autonomicznej pracy kosztuje mniej więcej tyle, co kilka tygodni subskrypcji ChatGPT Plus.

Czego agent nie zrobił samodzielnie:

• Nie napisał dokumentacji migracji dla zespołu (Codex nie zrozumiał, że to również część „migracji”)
• Nie zaktualizował plików konfiguracyjnych potrzebnych do publikowania z nową wersją Pydantic
• Przeoczył jedną regresję produkcyjną, którą wykryto dopiero dzień później

Innymi słowy, /goal wykonało 95% pracy, a pozostałe 5% nadal trzeba zrobić ręcznie. To normalne w przypadku obecnej generacji i nie jest powodem, by z tego narzędzia nie korzystać.

14 godzin pracy w nocy nad sterownikiem macOS#

Zadania, przy których to podejście przynosi największe korzyści:

• Prace niskopoziomowe, w których jedna iteracja i jej sprawdzenie zajmują kilka minut (kompilacja, uruchamianie testów)
• Migracje z jasno określonymi formalnymi kryteriami (typy, testy, lint)
• Testy porównawcze i optymalizacje z mierzalnymi wynikami
• Dokumentacja i dzienniki zmian o jasnej strukturze

Claude /goal równie dobrze sobie z tym radzi, ale przy sterownikach częściej wybiera się Codex, ponieważ sam sprawdza pliki i dzienniki, zamiast polegać na zewnętrznym sędzim.

Ile to kosztuje i jak uniknąć zużycia tokenów przez noc?#

Dane z publicznie opisanych przebiegów:

Najważniejsze, co trzeba zrozumieć: ani Claude Code, ani Codex nie zapewniają twardego limitu w rodzaju „przestań wydawać po osiągnięciu $N”. Istnieją trzy zabezpieczenia:

1. Limity subskrypcji — Pro, Max lub Enterprise. Przy planie Anthropic Max (100 USD miesięcznie) 14-godzinny nocny przebieg mieści się w tygodniowym limicie i pozostawia zapas
2. Limit tekstowy w warunku — wpisz bezpośrednio w /goal: „lub zatrzymaj się po 20 turach”. Sędzia Claude’a odczyta ten warunek i zamknie cel
3. Limit tokenów w Codex — wbudowany mechanizm, który po wyczerpaniu tokenów wstawia budget_limit.md

Co podbija rachunek podczas nocnej pracy:

• Niejasne kryterium, takie jak „zrób to wygodniejszym” — agent nigdy się nie zatrzyma, ponieważ ewaluator nie wie, co oznacza „lepsze”
• Dostęp do zewnętrznych API bez stubów — każda ponowna próba kosztuje tokeny
• Długi kontekst — po 6,7 mln tokenów rozpoczyna się kompresja kontekstu i część pamięci zostaje utracona

Więcej informacji o oszczędzaniu kosztów znajdziesz w przewodnikach na co idą tokeny Claude Code i jak nie wyczerpać limitów.

Kiedy NIE uruchamiać /goal: 5 sytuacji#

Dokumentacja OpenAI wprost wskazuje, czego NIE robić:

1. Jednowierszowe poprawki — użycie /goal do zmiany nazwy zmiennej kosztuje więcej niż ręczna zmiana
2. Niejasne cele — „popraw wydajność”, „uporządkuj kod”, „zrób to wygodniejszym”. Ewaluator nie ma kryterium, więc agent będzie krążyć bez końca
3. Produkcyjne bazy danych z danymi użytkowników — agent może zepsuć migrację, a przywrócenie danych z kopii zapasowej kosztuje więcej niż uzyskane oszczędności
4. Zmiany związane z bezpieczeństwem — uwierzytelnianie, szyfrowanie, obsługa płatności. Każdy commit musi tu zostać sprawdzony przez człowieka
5. Zewnętrzne API bez stubów — każda awaria sieci kosztuje tokeny i pozostaje poza Twoją kontrolą

Co zrobić, jeśli agent utknie?#

Jak szybko rozpoznać zapętlenie:

• Agent przez co najmniej 3 tury modyfikuje te same pliki, po czym przywraca ich poprzedni stan
• W dzienniku powtarzają się błędy, na które agent już wcześniej reagował
• Twoim zdaniem warunek jest spełniony, ale agent twierdzi, że „nie jest spełniony”
• Zużycie tokenów na turę rośnie, ale kod nie posuwa się naprzód

Co zrobić dalej:

• W Claude Code: użyj /goal clear, a następnie doprecyzuj warunek
• W Codex: użyj /goal pause, sprawdź bieżący wątek, zmień warunek poleceniem /goal edit, a następnie użyj /goal resume
• W obu narzędziach: sprawdź, czy kryterium da się rzeczywiście zweryfikować (polecenie zwraca kod wyjścia 0 lub generuje konkretny wynik)

Często przyczyną pętli jest samo zadanie, a nie agent. Warunek „wszystkie testy przechodzą” zakłada, że testy w ogóle mogą przejść. Jeśli w kodzie występuje głęboki problem architektoniczny, agent będzie krążył wokół jego objawów.

Kryteria ukończenia: dyscyplina zadań w /goal#

OpenAI jasno formułuje tę zasadę w oficjalnym Codex Cookbook:

Szablony kryteriów, które faktycznie się sprawdzają:

Połączenie w tabeli obejmuje testy, mypy i lint. Jeśli choć jedna kontrola nadal nie przechodzi, cel nie zostaje zamknięty. Ewaluator nie ma możliwości oszukiwania.

Antywzorce:

• „Kod jest lepszy”
• „Użyteczność wzrosła”
• „Wydajność się poprawiła”
• „Dokumentacja jest kompletna”

Różnica między „działa” a „nie działa” polega na możliwości weryfikacji. Jeśli kryterium nie da się sprawdzić poleceniem, nie da się go sprawdzić wcale. To właśnie OpenAI ma na myśli, mówiąc o „spójności w długim horyzoncie”: agent może myśleć przez długi czas, ale nie potrafi sam zdecydować, co oznacza „wystarczająco dobrze”.

Możesz przetestować pomysł „jeden prompt — jeden wynik” w prawdziwym projekcie: ustaw /goal, sformułuj kryterium, uruchom je i przeanalizuj, co poszło nie tak.

Poznaj Ailoot.