Codex a limity ChatGPT Plus: jak šetřit tokeny bez zastavení vývoje

Kdy limit začíná brzdit vývoj

Předplatné ChatGPT Plus sdílí pětihodinové a týdenní limity mezi Work a Codexem. Pětihodinové okno se nevyčerpává pouze podle počtu zpráv. Při každém běhu se znovu zpracovává systémový prompt, pravidla projektu, relevantní soubory, historie konverzace a výstupy nástrojů. Silnější model navíc spotřebuje více skrytých reasoning tokenů, i když je uživatel nevidí.

Počet dialogů proto není spolehlivým měřítkem spotřeby. V komunitní zkušenosti se nejčastěji uvádějí čtyři příčiny:

• silný model a vysoká úroveň reasoningu pro běžnou úlohu,
• opakované načítání stejného kontextu,
• podagenti nebo paralelní běhy zvětšující objem zpracovaného kontextu,
• příliš široké zadání bez rozumných mantinelů.

Jedna popsaná zkušenost s požadavkem „hloubkově otestovat aplikaci“ vedla přibližně k 70 000 simulacím místo běžné testovací sady. Silný model tedy nemusí být příčinou problému. Rozhodující může být zadání, které od agenta vyžaduje neomezené hledání chyb.

Nejprve ověřte zbývající allowance a čas resetu přes dashboard nebo příkaz /status v CLI. Odhad podle počtu zpráv je méně přesný. Po vyčerpání limitu můžete využít čekání na reset, kredity, vyšší plán nebo dostupný uložený či zakoupený reset. Úspornější prompt limit neobnoví.

Dál rozdělte práci na menší podúlohy a u každé stanovte jasný scope i test.

Rozdělení implementace na malé podúlohy

Diskuze mluví o „rozdělení práce“, ale přesnější je dekompozice zadání podle ohraničeného rozsahu a akceptačních kritérií. Každá podúloha potřebuje:

1. konkrétní změnu nebo výsledek,
2. omezený seznam souborů a oblastí,
3. podmínky, za kterých je úloha hotová,
4. test nebo jiný ověřitelný výstup.

Zadání „vylepši autentizaci“ neurčuje, co agent upraví ani kdy má skončit. Práce „přidej timeout k požadavku na obnovení tokenu, uprav jednotkový test a zkontroluj timeout bez změn v ostatních auth službách“ už jasně omezuje scope i výsledek.

Pravidla projektu rozdělte do modulů. Agent pak při každé úpravě nemusí načítat všechna pravidla UI, bezpečnosti, API a dokumentace. Vyhněte se ale opačnému extrému: příliš mnoho drobných vláken zvýší režijní náklady více, než ušetří kontext.

Každý krok uzavřete malým testem. Nejde o bezpečnostní funkci, ale o workflow s podmínkou „stop on green tests“. Pokud test neprochází, agent pokračuje v opravě téže úlohy. Nepřechází do nové implementace bez znalosti předchozího stavu.

Po rozdělení úloh je na řadě výběr modelu podle náročnosti práce.

Volba modelu podle náročnosti

Nejpraktičtější je model routing: model vybírejte podle typu práce a náročnosti rozhodnutí, nikoli podle názvu projektu.

• Silnější model: architektura, bezpečnost, plánování, složité debugování a rozhodnutí s více riziky.
• Střední model: běžná implementace, refaktoring, testy a opravy podle jasného zadání.
• Levnější model: dokumentace, přejmenování, formátování, jednoduché vyhledávání a podobné mechanické úkoly.

Rozdíl může být řádový. V jedné sadě odhadů z diskuse připadalo na pět hodin přibližně 5–45 lokálních zpráv u silnějšího modelu proti 350–3 000 u levnějšího. Jde o odhady z diskuse, nikoli o záruku výsledné kvality ani o přesné měření tokenů.

Hodnotu má také effort routing: vysoké uvažování patří do architektury a složitých výjimek, nikoli do každého formátování. Pokud levnější model selže dvakrát, zvyšte model nebo reasoning. Nečekejte hned na nejsilnějšího agenta. Silný model může auditovat výsledek, ale nemusí celý kód psát.

Jakmile víte, který model úlohu vyřeší, přesuňte rozhodnutí a stav do dalšího vlákna.

Kontext, handoff a cache

Handoff dokument má obsahovat jen to, co další vlákno potřebuje:

# Stav úlohy
[Cíl a rozsah]
Změněné soubory:
[seznam souborů]
Rozhodnutí a jejich důvod:
[stručné rozhodnutí]
Akceptační kritéria:
[testy a očekávané výsledky]
Otevřené otázky:
[seznam]

Takový dokument nahrazuje přenos celé konverzace. Nové vlákno je výhodné jen tehdy, když starý konverzační šum skutečně nepotřebujete. Přenos stovek řádků starého chatu jen přesune stejné tokeny do dalšího limitu.

Užitečný je také prompt caching. Opakovaný neměnný prefix lze znovu využít, protože se znovu zpracovává systémový prompt, pravidla projektu, relevantní soubory, historie a výstupy nástrojů. Cache ale může minout při změně jakéhokoli prefixu, včetně pravidel a pořadí souborů či nástrojů v promptu. Změna nastavení reasoning effort to může v praxi také způsobit. Stabilní, krátký prefix je proto výhodnější než neustále přepisované AGENTS.md.

Kompakce je vhodná, pokud vlákno stále potřebuje širší historii. Nové vlákno je vhodnější pro skutečně nový, ohraničený úkol.

Tím workflow šetří kontext. Jeho skutečný přínos ale ukáže až audit konkrétní relace.

Jak to funguje pod kapotou a kde má postup limity

Tento postup se odborně nazývá budget-aware agent workflow. Zahrnuje plánování, routing, izolaci kontextu a průběžnou kontrolu výsledků. Není to nová vlastnost Codexu; je to způsob řízení agentního workflow.

Rozdělení úkolů samo o sobě kvótu nezachrání. Pět malých běhů s plným kontextem může stát více než jeden přesně ohraničený běh. Handoff se navíc musí stát skutečným artefaktem. Výcuc celé diskuse kontext pouze přesune.

Podagenti jsou zvlášť rizikoví. Dokumentace nepotvrzuje, že každý podagent znovu zpracuje systémový prompt rodiče, pravidla projektu a celou stopu nástrojů. Podagent však běží ve vlastním vlákně a provádí vlastní modelovou a nástrojovou práci. Jejich použití proto může zvýšit celkovou spotřebu, i když uživatel napsal jen jedno zadání.

Největší limit metody je jednoduchý: workflow může odhalit příliš silný model, opakování nebo nevhodné zadání. Samo ale není přesným měřičem kvóty. Pro přesnější audit oddělte vstupní, cacheované vstupní, reasoning a výstupní tokeny a porovnejte je s časem a počtem skutečných změn.

Audit jedné relace

Audit začněte až po incidentu nebo jako pravidelnou kontrolu. Zapište:

• použité modely a úrovně reasoningu,
• cache hit a cache miss,
• podíl výstupů nástrojů,
• počet opakovaných testů,
• využití podagentů,
• počet commitů nebo skutečně změněných souborů,
• čas každého kroku.

Výsledky rozdělte do čtyř příčin: model, zadání, opakování a podagenti.

Pokud silný model vyřešil jedinou architektonickou změnu, může být oprávněný. Pokud levnější model generoval podobné opravy dvakrát, zpřesněte zadání nebo testy. Pokud pět podagentů jen zopakovalo stejnou kontrolu, přejděte na práci bez fan-outu.

Audit tak ukáže, kde limit brzdí vývoj a které změny workflow mají největší přínos.

Co si z toho vzít

• Měřte tokeny, čas a změny; počet zpráv není spotřeba.
• Silný model ponechte architektuře, bezpečnosti a těžkému debugu.
• Rozdělení musí mít scope, testy a akceptační kritéria.
• Handoff přenášejte jako krátký dokument, ne jako kopii konverzace.
• Podagenti mohou spotřebu zvýšit vlastní modelovou a nástrojovou prací; dopad je nutné měřit.
• Stabilní prefix a kompakce obvykle šetří více než nové vlákno s přebaleným zadáním.
• Nejprve omezujte rozsah testů a simulací; teprve potom měňte model nebo plán.