Proč agentní smyčky tiše vysávají rozpočet

Když vývojář zadá AI agentovi úkol — třeba „projdi kódovou základnu a najdi bezpečnostní zranitelnosti" — agent nespustí jednu operaci. Rozdělí úkol na kroky: načte soubor, analyzuje ho, spustí grep pro hledání vzorů, načte další soubor, porovná výsledky. Každý krok generuje nové tokeny. A každý další krok znovu posílá celou dosavadní historii do modelu.

Výzkumný tým společnosti Augment Code to pojmenoval přesně: „Naivní agentní smyčky skládají náklady na tokeny tempem O(N²), protože LLM API účtují celou historii konverzace při každém volání." Z desetikrokového agenta se tak nestane desetinásobek ceny jednoho volání — stane se až 43násobkem.

Klíčový problém není v ceně jednotlivých tokenů. Je v akumulaci kontextu. Tradiční chatovací API (například od Anthropicu nebo OpenAI) jsou bezstavová — při každém požadavku musíte poslat celou historii znovu. Agent, který v každém kroku přidá výstup nástroje, výsledek čtení souboru nebo stopu uvažování, nevědomky nafukuje účet exponenciálně.

Matematika, které vývojáři nerozumí

Augment Code publikoval vzorec, který přesně popisuje, jak se náklady hromadí:

Celkové vstupní tokeny = N×S + u×N(N+1)/2 + r×N(N−1)/2

Kde N je počet iterací, S jsou tokeny systémové výzvy, u nové tokeny na iteraci (zpráva uživatele + výsledek nástroje) a r výstupní tokeny na iteraci. Zlomový bod je výraz N(N+1)/2 — trojúhelníkové číslo, které roste kvadraticky, ne lineárně.

Konkrétní příklad pro Claude Sonnet 4.6 (ceník $3/$15 za milion vstupních/výstupních tokenů):

• Jeden průchod (single-pass): 9 000 tokenů = $0,03 (~0,70 Kč)
• Naivní 10kroková smyčka: 472 500 tokenů = $1,49 (~34 Kč) — 43× víc
• Optimalizovaná smyčka (okno 2 iterace): 260 000 tokenů = $0,86 (~19 Kč) — stále 29× víc

U dvacetikrokové úlohy je rozdíl ještě dramatičtější. Naivní přístup spotřebuje 1 795 000 tokenů za $5,54 (~125 Kč). Pokud vývojář spustí takovou úlohu padesátkrát denně, měsíční účet dosáhne téměř 140 000 Kč — za jediného vývojáře, za jediný měsíc.

Pět vzorů, jak zkrotit náklady na tokeny

Augment Code identifikoval pět architektonických vzorů, které lámou cyklus akumulace kontextu. Každý cílí na jiný aspekt problému a lze je vrstvit pro násobnou úsporu.

1. Izolace sub-agentů (Scope Limiting)

Práce se rozdělí mezi bezstavové sub-agenty, z nichž každý dostane jen kontext relevantní pro svůj dílčí úkol. Žádný sub-agent nevidí do vnitřností ostatních — rodičovský orchestrátor pouze syntetizuje výstupy. Benchmarky LangChain ukazují, že izolované sub-agenty spotřebují přibližně 9 000 tokenů oproti 15 000 u vzorů akumulujících kontext — úspora 40 %.

2. Resetování stavu s externí perzistencí

Namísto držení celé historie v kontextovém okně se stav ukládá do souborového systému, databáze nebo gitu. Agent se periodicky restartuje s čistým kontextem a navazuje prostřednictvím externích artefaktů. To řeší fenomén „Context Rot" — zhoršování kvality uvažování modelu, jak se kontextové okno plní.

3. Oddělení plánování od exekuce

Velký model vygeneruje kompletní plán před spuštěním nástrojů. Menší, levnější model pak provádí jednotlivé kroky. Plánovač se volá jednou, exekutor mnohokrát — ale s minimálním kontextem. Výzkum plan-then-execute potvrzuje strukturální snížení spotřeby tokenů.

4. Ořezávání a selektivní vkládání kontextu

Do kontextového okna vstupují pouze tokeny nezbytné pro bezprostředně následující krok. Výzkum explicitního plánování komprese na SWE-bench ukázal 22,7% úsporu tokenů při zachování přesnosti — ale pouze pokud je komprese explicitně instruována a plánována. Pasivní prompting snižuje spotřebu jen o 6 % a zhoršuje kvalitu.

5. Sumarizace konverzace

Když se kontext blíží limitu okna, historie se zkomprimuje do souhrnu. Claude Code například spouští auto-kompakci při zaplnění přibližně 83,5 % kontextového okna. Pozor: agresivní sumarizace může prodloužit dobu řešení úkolu (z průměrných 4 na 14 iterací v jednom měření), takže čistá úspora tokenů klesne na pouhých 14 %. Sumarizace funguje nejlépe na jasných fázových hranicích, ne jako průběžný kompresní механизmus.

Architektura koordinátor–specialista: Když jeden mozek nestačí

Nejefektivnější odpovědí na kvadratický růst nákladů je architektura koordinátor–specialista. Štíhlý koordinátor drží pouze logiku rozkladu úkolů, směrování a komprimované souhrny. Specialisté dostávají přesně vymezený kontext, zpracují svůj díl a vracejí komprimovaný výsledek.

Měření z výzkumu sdílených kontextových oken ukazuje 53,7% pokles spotřeby tokenů. GitHub Copilot tento princip aplikuje ve své paralelní agentní architektuře, kde každý sub-agent dostane vlastní kontextové okno, ale sdílí souborový systém. Koordinace probíhá přes I/O operace se soubory, ne přes kontextové okno — orchestrátor nikdy nereserializuje výstupy specialistů do své rostoucí historie.

Důležitý postřeh z výzkumu samoorganizujících se agentních systémů: plánovací vrstva by měla spotřebovat přibližně 9,8 % celkových tokenů, zatímco výkonní agenti 70,6 %. Pokud koordinátor spotřebovává výrazně víc, pravděpodobně akumuluje kontext, který měl delegovat.

Co to znamená pro české vývojáře a firmy

České technologické firmy patří mezi nejaktivnější adoptery AI programovacích nástrojů v Evropě. Nástroje jako GitHub Copilot (od 10 USD/měsíc, zhruba 225 Kč), Claude Code (součást Claude Pro za 20 USD, ~450 Kč/měsíc) nebo Cursor (20 USD/měsíc pro Pro verzi) jsou mezi českými vývojáři běžnou výbavou. Problém je, že fixní předplatné kryje jen část nákladů — skutečné API poplatky za agentní smyčky běží na pozadí a často překvapí až na faktuře.

Pro představu: středně velký český tým o deseti vývojářích, který každý den spustí v průměru 20 agentních úloh po 15 krocích na Claude Sonnet 4.6, může při naivní implementaci protopit přes 300 000 Kč měsíčně jen na API poplatcích. S aplikací vzorů pro omezení kontextu klesne tato částka na zhruba 80 000 Kč. Rozdíl čtvrt milionu korun měsíčně už není drobná položka v rozpočtu.

Z pohledu EU AI Actu je téma relevantní i regulatorně — akt požaduje transparentnost při nasazení AI systémů a firmy by měly být schopny doložit, jak jejich agenti nakládají s daty a jaké jsou provozní náklady. Nekontrolovaný růst tokenů může znamenat nejen finanční, ale i compliance riziko.

Jak monitorovat náklady, než překročí rozpočet

Augment Code varuje před skutečným incidentem z praxe: změna formátu API způsobila 200násobný nárůst spotřeby tokenů v produkčním agentním systému, což během 40 minut stálo přibližně 50 dolarů (~1 125 Kč). Tradiční monitoring infrastruktury (CPU, paměť) nic nezachytil — LLM volání jsou I/O vázaná a pouze sledování tokenů na úrovni úloh odhalilo anomálii.

Čtyři klíčové metriky, které by měl sledovat každý tým nasazující AI programátory:

• Tokeny na úlohu: při překročení dvojnásobku baseline spustit alert — kvadratický růst se projeví dřív, než stihne vyprázdnit účet
• Cena za dokončení: denní útrata překračující historický průměr signalizuje problém
• Počet iterací na úlohu: dvojnásobek běžného průměru znamená smyčku opakovaných pokusů nebo zastaralý plán
• Poměr využití kontextu: překročení 85 % okna aktivuje sumarizační mechanismy a může znamenat přechod do dražší cenové kategorie (například u Gemini API se nad 200K tokeny zdvojnásobuje sazba)

Pro sledování těchto metrik jsou k dispozici nástroje jako LangSmith (integrace s PagerDuty), Langfuse (open-source, self-hosted), Helicone (AI Gateway bez nutnosti změny kódu) nebo Portkey (multi-provider podpora). Všechny nabízejí per-step atribuci nákladů a podporu OpenTelemetry, takže je lze začlenit do existujícího monitoringu.

Zásadní ponaučení z analýzy Augment Code zní: omezujte kontext dřív, než začnete škálovat počet agentů. Začněte měřením tokenů na úlohu u existujících workflow, identifikujte smyčky s největší akumulací kontextu a aplikujte scope limiting nebo state resety. Teprve poté investujte do plnohodnotné architektury koordinátor–specialista. Jinak platíte za každý token historie — znovu a znovu.