# A Claude Code és a Codex éjszakai futtatása a /goal segítségével 2026-ban: 14 órás önálló mód
> A Claude Code 2.1.139 és a Codex CLI /goal parancsa órákon át önállóan futtat egy AI-ügynököt. Bemutatom a beállítást, valódi példákat és a tokenköltséget.
Source: https://ailoot.ai/blog/hu/goal-mode-claude-code-codex/
Canonical: https://ailoot.ai/blog/hu/goal-mode-claude-code-codex/
Language: hu
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-103
Revision: sha256-64c26b8da05beabdf0dd6ec5efd33f2a993cfa5582f07ad4cf0cc15145a10e57
Főbb tudnivalók
A `/goal` parancs a Claude Code 2.1.139-ben (2026. május 11.) és a Codex CLI 0.128.0-ban (2026. április 30., május 21. óta stabil) jelent meg. Ön egyszer meghatározza a „kész” feltételét, az ügynök pedig önállóan végigmegy a tervezés, a végrehajtás és az ellenőrzés ciklusán, amíg a feltétel teljesül, vagy el nem fogynak a tokenek. Az OpenAI nyilvánosan bemutatott egy 25 órás futást, amely 13 millió tokent használt fel. Ez a megoldás jól alkalmazható migrációkhoz, benchmarkokhoz és mérhető feltételekkel végzett refaktoráláshoz. UI-feladatokhoz, éles adatbázisokhoz vagy olyan homályos kérésekhez nem való, mint a „legyen jobb”.
Az Ailoot használatáról a [dokumentációban](https://ailoot.ai/docs/) talál információt.
## Mi az a `/goal`, és miért jelent meg 2026-ban?
Főbb tudnivalók
A `/goal` előtt minden ügynöki körhöz kézzel kellett beírni a „folytasd” utasítást. Az ügynök megnyitott egy fájlt, elolvasta, írt valamit, leállt, majd várt. A `/goal` parancs egyszer állít be egy befejezési feltételt: az ügynök maga dönti el, mikor készült el a feladattal, és addig nem adja vissza az irányítást, amíg be nem fejezte.
Így nézett ki a helyzet, amelyet mindannyian ismertünk 2026 áprilisa előtt: adok Claude-nak egy feladatot: „migráld a projektet Pydantic v1-ről v2-re”. Elkezd dolgozni, 30 másodperc után leáll, megnézem, mit csinált, beírom, hogy „folytasd”, megteszi a következő lépést, leáll, én pedig újra beírom, hogy „folytasd”. Egy nagy migráció esetén ez 200–300 kézi „folytatást” jelent, így lényegében az ügynököt felügyelem ahelyett, hogy közben más kódot írnék.
Az OpenAI elemzése szerint nem a modell „butasága” jelentette a problémát, hanem a ciklus architektúrája. A modell nem tudta, mikor kell leállnia, ezért minden körben fékezett. Ha megadunk neki egy „kész” feltételt, maga dönti el.
Így született meg a `/goal` — a harnessbe, nem pedig a modellbe épített mechanizmus.
Ez a megjegyzés a Code with Claude konferencián hangzott el Londonban, 2026. május 19–20-án. Azt írja le, mi történt a `/goal` mindkét eszközben való megjelenése utáni hónapban.
## Hogyan állítható be a Goal mód a Claude Code-ban?
Főbb tudnivalók
A Claude Code 2.1.139 2026. május 11-én jelent meg a `/goal` paranccsal. Egy kis modell (alapértelmezés szerint Haiku) minden kör után ellenőrzi a feltételt. Ha a feltétel nem teljesül, Claude újabb kört fut. A feltétel legfeljebb 4,000 karakteres lehet, és munkamenetenként egy goal adható meg.
Egy minimális példa az Anthropic hivatalos dokumentációjából:
```bash
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"
```
Ez a parancs egy goal-lal indítja el az ügynököt a háttérben. Claude megkeresi a PR-eket, összeveti őket a CHANGELOG.md tartalmával, hozzáadja a hiányzó sorokat, majd leáll, amikor teljesül a feltétel.
Interaktív módban csak írja be a `/goal` parancsot, utána pedig a feltételt:
```
/goal all pytest tests pass and mypy strict reports zero errors
```
Ezután Claude a következőket teszi:
- Minden kör után egy különálló, gyors modell (alapértelmezés szerint Haiku) megkapja az aktuális feltételt és a beszélgetési előzményeket
- Ez a modell rövid indoklással „igen” vagy „nem” választ ad
- Ha a válasz „nem”, Claude automatikusan újabb kört fut anélkül, hogy visszaadná Önnek az irányítást
- Ha a válasz „igen”, a goal törlődik, és visszakapja az irányítást
Minden kör után egy kicsi, gyors modell ellenőrzi, hogy teljesült-e a feltétel. Ha nem teljesült, Claude újabb kört indít anélkül, hogy visszaadná Önnek az irányítást.
— Hivatalos Claude Code-dokumentáció, https://code.claude.com/docs/en/goal
Szigorú korlátozások, amelyekről csak akkor értesül, amikor beleütközik valamelyikbe:
- A `/goal` csak olyan munkakönyvtárakban működik, amelyeknél elfogadta a bizalmi párbeszédablakot. Ha új gépet használ, és Claude még nem jegyezte meg a könyvtárat, a parancs hibát jelez
- A `disableAllHooks` vagy `allowManagedHooksOnly` beállítású vállalati környezetekben a parancs nem érhető el
- A feltétel legfeljebb 4,000 karakteres lehet
- Munkamenetenként csak egy goal lehet aktív. Egy új `/goal` felülírja a régit
- A `--resume` megőrzi a feltételt, de a körök, az idő és a tokenek számlálóját visszaállítja
Vezérlőparancsok:
- `/goal` argumentum nélkül — megjeleníti az aktuális állapotot
- `/goal clear` (vagy `stop`, `off`, `reset`, `none`, `cancel`) — törli a goal-t
Az Anthropic szerint az értékelő költsége „általában elhanyagolható a fő kör költségéhez képest”. A Haiku kiértékeli a feltételt és a beszélgetés szövegét, de nem hív eszközöket, ezért az ellenőrzés olcsó; a drága részt a fő modell körei jelentik.
## Hogyan állítható be a `/goal` a Codex CLI-ben?
Főbb tudnivalók
A Codex CLI 0.128.0 2026. április 30-án kísérleti funkcióként adta hozzá a `/goal` parancsot. Május 21-én a mód stabil lett a 26.519-es kiadásban / npm 0.133.0-ban. Két prompt sablonon keresztül működik: `continuation.md` („folytasd”) és `budget_limit.md` („állj le”). A goal a threadhez kötődik, és újraindítás után is megmarad.
A parancs ugyanúgy néz ki, mint a Claude esetében:
```bash
codex
> /goal all vitest tests pass and there are no eslint errors
```
A Codex több goal-vezérlési lehetőséget kínál:
| Parancs | Művelet |
|-----------------|---------------------------|
| `/goal condition` | goal beállítása |
| `/goal` | állapot megtekintése |
| `/goal pause` | szüneteltetés |
| `/goal resume` | folytatás |
| `/goal edit` | feltétel módosítása (GA-val) |
| `/goal clear` | goal törlése |
A fő különbség Claude-hoz képest az, hogy a Codex maga ellenőrzi, „kész van-e”, nem pedig egy külön modell. Minden kör után a Codex automatikusan beilleszti az `openai/codex` tárolóból származó `continuation.md` sablont a kontextusba. Szó szerinti fordításban:
> „Folytasd a munkát az aktív thread goal elérése érdekében. Ne ismételd meg a már elvégzett munkát. Válaszd ki a következő konkrét lépést a goal felé. Csak akkor jelöld elértnek a goal-t, ha egy audit igazolja, hogy az valóban teljesült, és nem maradt hátra elvégzendő munka.”
Amikor a tokenek elérik a határukat, egy második sablon, a `budget_limit.md` kerül beillesztésre:
> „A goal elérte a tokenkorlátját. Ne kezdj bele jelentősebb új munkába. Zárd le ezt a kört a lehető leghamarabb: foglald össze a hasznos előrelépést, azonosítsd a fennmaradó munkát és az akadályokat, majd adj egyértelmű következő lépést a felhasználónak.”
A logika ugyanaz: „ne hazudj arról, amit elvégeztél”. A folytatási szabály szerint csak akkor kell folytatni, ha a goal valóban nem teljesült. A budget_limit leállásra utasít, de őszintén le kell írni, mi maradt hátra.
Claude-tól eltérően a Codex a threadhez köti a goal-t, nem a munkamenethez. Például este bezárhatod a terminált, reggel pedig újra megnyithatod, és a `/goal resume` ugyanazzal a goal-lal folytatja a munkát, a memóriában ugyanazokkal a tényekkel. Ez hasznos, ha a futást a saját időbeosztása szerint több részre osztja.
## Miben különbözik a Claude Code és a Codex `/goal` parancsa?
Főbb tudnivalók
Claude szétválasztja az író és a bíró szerepét: a fő modell kódot ír, egy különálló kis modell pedig értékeli az eredményt. A Codex egyetlen ügynök, amely a saját munkáját ellenőrzi — emlékezteti magát: „ne hazudj arról, amit elvégeztél”. Az architektúrák eltérnek, de a végtelen ciklus kockázata ugyanaz.
Ez a leggyakoribb hiányosság az összehasonlításokban, ezért nézzük meg részletesen.
| Szempont | Claude Code `/goal` | Codex `/goal` |
|----|----|----|
| Kiadás | v2.1.139, 2026. május 11. | v0.128.0, 2026. április 30. (kísérleti) → v0.133.0 / 26.519, 2026. május 21. (stabil) |
| Goal hatóköre | Munkamenet | Thread (újraindítás után is megmarad) |
| Vezérlők | `set`, `clear` (+ álnevek) | `set`, `view`, `pause`, `resume`, `edit`, `clear` |
| Ki ellenőrzi, hogy „kész van-e” | Külön modell (alapértelmezés szerint Haiku) | Maga az ügynök, egy beillesztett prompt segítségével |
| Az értékelő hozzáférése a fájlokhoz | Nincs; csak a beszélgetés szövege alapján értékel | Van; megvizsgálhat fájlokat, teszteket és naplókat |
| Korlát | A feltétel szövegében: „vagy állj le 20 kör után” | Beépített tokenkorlát + a `budget_limit.md` automatikus beillesztése |
| Szigorú költési limit | Nincs; csak az előfizetési korlát | Nincs; csak az előfizetési korlát |
| A feltétel hossza | Legfeljebb 4,000 karakter | Nincs megadva |
| Hol működik | Interaktív mód, `-p`, asztali alkalmazás, Remote Control | Alkalmazás, IDE-bővítmény, CLI, ACP-kliensek |
A fogalmi különbség az, hogy Claude a ciklust minőségi szerződésként kezeli (külső értékelővel), a Codex pedig végrehajtási mechanizmusként (az ügynök maga kezeli a folyamatot).
A gyakorlatban ez azt jelenti, hogy ha azt szeretné, hogy a „kész” feltételt elfogulatlan értékelő vizsgálja meg, válassza Claude-ot. Ha azt szeretné, hogy az ügynök az értékelés során fájlokat és naplókat is ellenőrizhessen, válassza a Codexet.
Az eszközökről további információt a [Codex és Claude Code összehasonlító útmutatójában](https://ailoot.ai/blog/hu/codex-vs-claude-code-choice/) talál.
## Valódi példa: migráció Pydantic v1-ről v2-re 31 óra alatt
Főbb tudnivalók
A Codex `/goal` 31 óra valós idő alatt, négy munkamenetre bontva migrálta egy belső szolgáltatás 14,000 sorát Pydantic v1-ről v2-re. A költség körülbelül $44 volt gpt-5.3-codex használatával.
A feladat így szólt: „migrálj Pydantic v1-ről v2-re, minden pytest-tesztnek át kell mennie, a mypy strict pedig nulla hibát jelezzen.”
Ez történt:
- 1. munkamenet (8 óra)—A Codex elemezte az importokat, átírta a `BaseModel` deklarációkat, és beállította a mypy-t
- 2. munkamenet (10 óra)—átírta a validátorokat, és körülbelül 200 tesztet elrontott
- 3. munkamenet (7 óra)—kijavította a teszteket, és körkörös függőségeket talált
- 4. munkamenet (6 óra)—megoldotta a megmaradt mypy-hibákat és regressziókat
Tokenköltség:
> „A teljes eltelt idő körülbelül 31 óra volt négy munkamenet alatt. A gpt-5.3-codex díjszabásával számított teljes Codex-tokenköltség körülbelül \$44.”
Az árat főként a gpt-5.3-codex kimeneti tokenjei határozzák meg, amelyek díja milliónként \$14. Ez azt jelenti, hogy 31 óra önálló munka körülbelül annyiba kerül, mint egy ChatGPT Plus-előfizetés több hétre.
Amit az ügynök nem végzett el önállóan:
- Nem írt migrációs dokumentációt a csapat számára (a Codex nem értette, hogy ez a „migráció” része)
- Nem frissítette a Pydantic új verziójával történő közzétételhez szükséges konfigurációs fájlokat
- Nem vett észre egy éles környezetben jelentkező regressziót, amelyet csak egy nappal később fedeztek fel
Más szóval, a `/goal` elvégezte a munka 95%-át; a fennmaradó 5%-ot továbbra is kézzel kell elvégezni. Ez normális a jelenlegi generációnál, és nem ok arra, hogy ne használjuk.
## 14 órán át futó macOS-driver egy éjszaka alatt
## Mely feladatok alkalmasak hosszú éjszakai futásokra
Főbb tudnivalók
A driverek olyan feladatkategóriát alkotnak, amelyhez az interaktív munka rosszul illik, a hosszan futó ciklusok viszont jól megfelelnek.
Azok a feladattípusok, amelyeknél ez a megközelítés a legnagyobb előnyt nyújtja:
- Alacsony szintű munka, ahol egy iteráció és annak ellenőrzése percekig tart (fordítás, tesztfuttatás)
- Migrációk egyértelmű, formális feltételekkel (típusok, tesztek, lint)
- Mérhető eredményű benchmarkok és optimalizálások
- Dokumentáció és changelogok világos szerkezettel
A Claude `/goal` ugyanilyen jól elvégzi ezt a munkát, de driverekhez gyakrabban választják a Codexet, mert külső bíró helyett maga ellenőrzi a fájlokat és a naplókat.
## Mennyibe kerül, és hogyan kerülhető el a tokenek éjszakai elhasználása?
Főbb tudnivalók
A `/goal`-nak nincs felső, szigorú költési korlátja — csak az előfizetési csomag korlátai érvényesek. A Codex egy valós órája körülbelül $1.50–$3-ba kerül gpt-5.3-codex használatával. Claude futtatása többe kerül, az értékelése viszont kevesebbe. Az egyetlen védőkorlát, ha magába a feltételbe írja: „vagy állj le N kör után”.
Nyilvános beszámolókból származó adatok:
| Futás | Időtartam | Tokenek | Költség |
|----|----|----|----|
| OpenAI-tervezőeszköz bemutatója | 25 óra | 13M | (belső futás) |
| Pydantic v1→v2 | 31 óra, 4 munkamenet | ~3.1M kimeneti token | ~\$44 |
| Hangalapú interjúrendszer | összesen 6 óra 44 perc (41 perc számítás) | 6.8 millió bemeneti token, 94% gyorsítótárazva | \- |
| Betűtípus-smoketeszt | 5 perc | 188,832 | a heti kvóta kevesebb mint 5%-a |
A legfontosabb tudnivaló: sem a Claude Code, sem a Codex nem biztosít szigorú „állítsd le a költést $N-nél” korlátot. Három védőkorlát létezik:
1. **Előfizetési korlátok** — Pro, Max vagy Enterprise. Az Anthropic Max csomagjában ($100/hónap) egy 14 órás éjszakai futás belefér a heti keretbe, és marad is tartalék
2. **Szöveges korlát a feltételben** — írja bele közvetlenül a `/goal` parancsba, hogy „vagy állj le 20 kör után”. Claude bírája elolvassa, és lezárja a goal-t
3. **Tokenkorlát a Codexben** — beépített mechanizmus, amely a tokenek elfogyásakor beilleszti a `budget_limit.md` fájlt
Ami éjszaka megnöveli a számlát:
- Egy homályos feltétel, például „legyen kényelmesebb” — az ügynök sosem áll le, mert az értékelő nem tudja, mit jelent a „jobb”
- Külső API-khoz való hozzáférés stubok nélkül — minden újrapróbálkozás tokenekbe kerül
- Hosszú kontextus — 6.7M token után elindul a kontextus tömörítése, és elveszhet a memória egy része
A költségmegtakarításról bővebben a [hová tűnnek a Claude Code tokenjei](https://ailoot.ai/blog/hu/where-claude-code-tokens-go/) és az [így kerülheti el a keretek elhasználását](https://ailoot.ai/blog/hu/claude-code-token-limits-saving/) útmutatóban olvashat.
## Mikor NE futtassa a `/goal`-t: 5 helyzet
Főbb tudnivalók
Homályos feltételek, például „nézzen ki jól”, egysoros módosítások, felhasználói adatokat tartalmazó éles adatbázisok, biztonságkritikus változtatások és nem egyértelmű külső függőségekkel járó feladatok. Mind az öt helyzetben az ügynök vagy végtelen ciklusba kerül, vagy értelmetlenül égeti a tokeneket.
Az OpenAI dokumentációja kifejezetten leírja, mit NE tegyen:
1. **Egysoros módosítások** — egy változó átnevezéséhez a `/goal` futtatása többe kerül, mint a kézi átnevezés
2. **Homályos goalok** — „javítsd a teljesítményt”, „legyen tisztább a kód”, „legyen kényelmesebb”. Az értékelőnek nincs mércéje, ezért az ügynök végtelenül pörög
3. **Felhasználói adatokat tartalmazó éles adatbázisok** — az ügynök elronthat egy migrációt, az adatmentésből való visszaállítás pedig többe kerül, mint bármilyen megtakarítás
4. **Biztonsági változtatások** — hitelesítés, titkosítás, fizetésfeldolgozás. Ezeknél minden commitot embernek kell átnéznie
5. **Külső API-k stubok nélkül** — minden hálózati hiba tokenekbe kerül, és kívül esik az Ön ellenőrzésén
## Mit tegyen, ha az ügynök elakad?
Főbb tudnivalók
A ciklus jele, ha az ügynök 3–4 körön át ugyanazt a részt szerkeszti, majd visszavonja a módosításokat. Szakítsa meg Ctrl+C-vel, ellenőrizze a naplót, majd szigorítsa a feltételt, vagy szűkítse a feladatot egyetlen részre. Claude-ban a `/goal clear` segít; Codexben használja a `/goal pause` parancsot, és szerkessze a feltételt.
Így ismerhető fel gyorsan a ciklus:
- Az ügynök 3+ körön át ugyanazokat a fájlokat módosítja, majd visszaállítja az eredeti állapotot
- A naplóban ismétlődnek olyan hibák, amelyekre az ügynök már reagált
- Ön szerint teljesült a feltétel, de az ügynök azt mondja, hogy „nem teljesült”
- Körönként nő a tokenhasználat, de a kód nem halad előre
A következő teendők:
- Claude Code-ban: `/goal clear`, majd tegye pontosabbá a feltételt
- Codexben: `/goal pause`, vizsgálja meg az aktuális threadet, szerkessze a feltételt a `/goal edit` paranccsal, majd használja a `/goal resume` parancsot
- Mindkét esetben: ellenőrizze, hogy a feltétel valóban igazolható-e (egy parancs 0 kilépési kódot ad vissza vagy meghatározott kimenetet állít elő)
A ciklust gyakran maga a feladat okozza, nem az ügynök. A „minden teszt sikeres” feltétel azt feltételezi, hogy egyáltalán sikeresek lehetnek a tesztek. Ha a kódban komoly architekturális probléma van, az ügynök újra és újra a tünet körül fog körözni.
## „Kész” feltételek: fegyelmezett feladatmegadás a `/goal`-hoz
Főbb tudnivalók
A jó feltétel egy olyan parancs, amely 0 kilépési kódot ad vissza, vagy meghatározott kimenetet állít elő. A „minden teszt sikeres” működik. „Legyen tisztább a kód” nem. A legjobb egy formális ellenőrzést mérhető mutatóval kombinálni — például tesztekkel és minimális lefedettséggel.
Az OpenAI hivatalos Codex Cookbookja egyértelműen fogalmazza meg ezt a szabályt:
Egy goal nem tekinthető befejezettnek pusztán azért, mert a modell annak gondolja. A goal csak akkor teljesült, ha az eredményt fájlokkal, tesztekkel, naplókkal, benchmarkokkal vagy más konkrét artefaktumokkal összevetve ellenőrizték.
— OpenAI Codex Cookbook, Goalok használata a Codexben, https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex
Valóban működő feltételsablonok:
| Feltétel típusa | Megfogalmazása |
|----|----|
| Tesztek | „a pytest tests/ 0 kilépési kódot ad vissza, a lefedettség pedig legalább 80%” |
| Típusok | „a mypy strict nulla hibát jelez a src/ könyvtárban” |
| Lint | „az eslint . 0 kilépési kódot ad vissza minden módosított fájlra” |
| Build | „az npm run build sikeresen lefut TypeScript-hibák nélkül” |
| Benchmark | „a k6 run perf test p95 értéke 200 ms alatt van” |
| Diff | „a git diff csak az X, Y, Z fájlok változásait mutatja” |
| Kombinált | „a pytest sikeres ÉS a mypy strict nulla hibát jelez ÉS a ruff check sikeres” |
A Combo példa kombinációt használ: teszteket, mypy-t és lintet. Ha akár egy ellenőrzés is sikertelen, a goal nincs lezárva. Az értékelőnek nincs lehetősége csalni.
Ellenpéldák:
- „Jobb a kód”
- „Javult a használhatóság”
- „Javult a teljesítmény”
- „Elkészült a dokumentáció”
A „működik” és a „nem működik” közötti különbség az ellenőrizhetőség. Ha egy feltétel nem ellenőrizhető paranccsal, akkor egyáltalán nem ellenőrizhető. Az OpenAI „hosszú távú koherencia” alatt is ezt érti: az ügynök hosszú ideig gondolkodhat, de nem döntheti el maga, mi számít „elég jónak”.
Egy valódi projekten is kipróbálhatja az „egy prompt — egy eredmény” elvét: állítson be egy `/goal`-t, fogalmazza meg a feltételt, futtassa le, majd elemezze, mi romlott el.
Ismerje meg az [Ailootot](https://ailoot.ai/).
## Kérdések és válaszok: A Claude Code és a Codex éjszakai futtatása a /goal segítségével 2026-ban: 14 órás önálló mód
### Mi a hasznos /goal-befejezési feltétel?
Ellenőrizhető eredményt adj: nevezd meg a tesztet, típusellenőrzést, buildet vagy benchmarkot és szükséges eredményét. A kért ellenőrzéseket kifejezetten kösd össze, és add meg az engedélyezett fájlhatókört; a „legyen jobb” nem mérhető leállási pont.
### Mit tegyek, ha az ügynök ugyanazokat a sikertelen szerkesztéseket ismétli?
Szakítsd meg a futást, és nézd át a naplót. Ha ugyanazokat a fájlokat módosítja és visszaállítja, szűkítsd a feladatot vagy pontosítsd a feltételt; folytatás előtt igazold, hogy a szükséges ellenőrzések egyáltalán teljesíthetők.
## Ailoot · A vállalat és projektportfóliója
Az Ailoot felhalmozott működési tapasztalatra, széles ügyfélkörre, stabil szolgáltatásra és folyamatos KPI-ellenőrzésre épít.
A vállalat és projektportfóliója: ügyfelek milliói; havi értékesítés milliárdos nagyságrendben.
Az Ailoot ezt a működési tapasztalatot használja az ügyfelek termékeiben, ágenseiben, alkalmazásaiban és automatizálásaiban elérhető AI-funkciók API-hozzáféréséhez.