Utrácení tokenů je problém architektury, ne rozpočtu

Než letos vůbec přišel duben, Uber už stihl utratit celý svůj AI rozpočet na rok 2026, což je fakt divná věta na napsání, a reakce napříč oborem byla skoro čistě finanční. Microsoft odebral velké části svého vlastního engineeringu licence na Claude Code. Gartner začal roztáčet prognózu, že náklady na AI kódování překonají do roku 2028 průměrný plat vývojáře. Nákupní oddělení všude začala kreslit stropy tokenů na uživatele, měsíční limity a dashboardy, které se rozsvítí červeně, jakmile někdo spustí o pár agentických smyček víc. To všechno je jako léčit horečku dekou. Faktura explodovala, protože systémy, které ty tokeny generují, byly navržené ledabyle, a žádná míra rozpočtové governance neopraví systém, který do každého jednoho requestu nacpe 180 tisíc tokenů irelevantního kontextu. Postavili jsme jich už dost, document pipeliny, interní copiloty, support agenty pro zákazníky, takže můžeme s klidem říct, že utrácení tokenů kopíruje architektonickou lenost skoro dokonale. Pokud vás vaše náklady děsí, je to diagnostická informace o vašem designu, ne o vašem finančním oddělení. Firmy, co panikaří kvůli výdajům, jsou obvykle ty, které agenta zdrátovaly tak, aby při každém kroku vysypal celou codebase do kontextu, protože to bylo jednodušší než postavit retrieval, a pak se tvářily překvapeně, když přišla faktura. Z tohohle se rozpočtem neproškrtáte. Můžete se z toho jen prostavět.

Nejčastější chyba, kterou vidíme, a objevuje se asi v osmi z deseti agent codebase, které auditujeme, je zacházet s context window jako s bezplatným poznámkovým blokem, který nacpete, abyste se cítili v bezpečí. Někdo si přečte, že model podporuje 200 tisíc nebo milion tokenů kontextu, a rozhodne se, že správný tah je narvat tam všechno, co se fyzicky vejde, kompletní historii konverzace, každý retrieved dokument, celé schéma, tři ukázkové výstupy a system prompt, který nabobtnal na 4 000 slov, protože z něj nikdy nikdo nic nesmaže. Každý token v tom okně se účtuje při každém kroku, a v agentické smyčce se ten krok stane dvacetkrát nebo třicetkrát, než se dokončí jeden úkol. Vyřešení jednoho support ticketu může nasekat dva miliony účtovaných input tokenů, ne protože je práce těžká, ale protože ten samý nabobtnalý kontext veze s sebou při každé iteraci. Oprava je nudná. Agresivně ořezáváte, co do okna jde, staré kroky konverzace shrnujete místo toho, abyste je vezli doslova, retrievujete tři nejrelevantnější chunky místo padesáti a mažete ty části system promptu, které tam přibyly kvůli opravě bugu, co už dávno neexistuje. Měli jsme klienta s agentem na klasifikaci dokumentů, který při každém volání předával celý zdrojový dokument plus všechna předchozí klasifikační rozhodnutí. Rozdělení do retrieval kroku, který vytáhl jen relevantní sekce, srazilo náklady na dokument zhruba o sedmdesát procent a přesnost stoupla, protože se model přestal topit v šumu. Větší kontext je schopnost, ne strategie.

Anthropic i OpenAI nabízejí prompt caching a je to skoro to nejpákovější, co můžete s běžícím agentem udělat, a přesto šokující počet týmů buď neví, že existuje, nebo se nikdy neobtěžoval ho správně zapojit. Myšlenka je jednoduchá. Váš system prompt, definice nástrojů, few-shot příklady, velký statický kontext, který je identický napříč requesty, to všechno se dá cachovat na straně serveru, takže při cache hitu platíte zlomek běžné input sazby místo plné ceny pokaždé. Anthropic vám dá něco jako devadesátiprocentní slevu na cachovaná čtení. U agenta, kde je prvních 30 tisíc tokenů každého requestu byte po bytu identických, což popisuje skoro každého agenta s fixním system promptem a sadou nástrojů, necháváte na stole obrovské úspory tím, že si requesty nestrukturujete tak, aby trefily cache. Háček je v tom, že caching je prefixový, takže cachovaný obsah musí být první a zůstat stabilní. Pokud dynamický obsah prokládáte na začátku promptu, cache při každém requestu odpálíte a nemáte nic. Takže to přeskládáte. Statické věci nahoru, označené k cachování, dynamické dolů. Přestavěli jsme takhle support agenta jednoho zákaznického portálu a jejich měsíční faktura od Anthropicu klesla o něco přes polovinu bez jakékoli změny kvality výstupu, čistě správným pořadím promptu a nastavením cache breakpointů. To není optimalizace, to je zvedání peněz z chodníku.

Další strukturální selhání je posílat každý request na váš nejdražší model, protože dává nejlepší odpovědi, což je pravda a zároveň velkolepý způsob, jak zapálit peníze. Většina toho, co agenti reálně dělají, není těžká. Klasifikace intentu, vytažení pole z formuláře, rozhodnutí, který nástroj zavolat dál, přeformátování nějakého JSONu, nic z toho nepotřebuje frontier model, a přesto týmy routují celou pipelinu přes top model, protože postavily jednu cestu a nikdy ji nerozdělily. Model routing znamená, že se podíváte na úkol před sebou a vyberete nejlevnější model, který ho zvládne spolehlivě. Malý rychlý model zvládne klasifikaci a routovací rozhodnutí, střední model zvládne většinu generování a k drahému modelu eskalujete jen tehdy, když úkol reasoning fakt potřebuje. Můžete dokonce postavit fallback, kde se o úkol nejdřív pokusí levný model a confidence check ho posune k většímu jen v případě potřeby. Tohle ale vyžaduje, abyste reálně měřili, který úkol potřebuje který model, místo hádání, a abyste postavili eval set, ať víte, kdy downgrade škodí kvalitě, což je reálná práce, kterou většina týmů přeskočí. Obvykle to stavíme jako tenkou router vrstvu v Go, která sedí před poskytovateli modelů a dělá klasifikaci, správu cache a eskalační logiku na jednom místě, takže aplikační kód nemusí vědět ani řešit, který model odpověděl. Dobře naroutovaná pipeline běžně jede většinu volání na modelech, které stojí zlomek frontier tieru, a uživatel to nikdy nepozná, protože frontier model pořád řeší ty části, co jsou fakt těžké.

Nemůžete opravit to, co neměříte, a skoro nikdo neinstrumentuje náklady na tokeny v takové granularitě, aby to plýtvání odhalilo. Měsíční faktura vám řekne, že jste utratili děsivou částku, ale ne že devadesát procent z toho pocházelo z jedné špatně navržené retry smyčky ve vaší ingestion pipeline, která při každém selhání znovu posílá celý kontext. Chcete atribuci nákladů na request, na agenta, na typ úkolu, jak vám teče do jakéhokoli tracing setupu, který už provozujete, otagovanou tak, abyste to mohli krájet podle feature a podle modelu, a chcete to viditelné pro inženýry, kteří ten agent kód píšou, ne jen pro finance tři týdny po tom. Když inženýr vidí, že změna, kterou právě shipnul, zdvojnásobila průměrný náklad na konverzaci, opraví to ještě to odpoledne. Když se to dozví z tabulky na konci kvartálu, už to krvácí peníze celé měsíce. Je to ta samá disciplína, jakou aplikujeme na latenci a chybovost už deset let, jen namířená na novou osu. Otagujte své spany input tokeny, output tokeny, cachovanými tokeny, použitým modelem a náklady v dolarech, a najednou se ty drahé části vašeho systému stanou zřejmými místo záhadných.

Uberův kolaps a Microsoft rušící licence se čtou jako varovné příběhy o tom, že je AI moc drahá, a to čtení je líné přesně stejně, jako byly líné ty architektury pod tím. Technologie není předražená. Systémy postavené nad ní byly postavené bez jakékoli nákladové disciplíny, kterou bychom u databázových dotazů, API volání nebo alokace paměti považovali za samozřejmost. Nikdo by neshipnul službu, která při každém requestu jede full table scan, a pak neobviňoval cloud providera, když přijde faktura, jenže přesně to funkčně dělá agent, který si při každém kroku nacpe celé context window. Týmy, které utíkající útratu za tokeny berou jako problém nákupu, stráví další dva roky bojem s vlastními inženýry přes rate limity a schvalovací workflow, škrtí přesně ten výstup, kvůli kterému ty nástroje pořizovaly, zatímco týmy, které to berou jako problém designu, ořežou kontext, nacachují prefixy, naroutují podle složitosti, zinstrumentují svou útratu a v tichosti poženou ty samé workloady za pětinu ceny. Ve steezru tyhle pipeliny stavíme klientům dost dlouho na to, abychom věděli, že úspory jsou reálné a opakovatelné a že přicházejí z inženýrských rozhodnutí, ne z rozhodnutí v tabulce. Faktura vám o vaší architektuře říká něco konkrétního. Přečtěte si ji jako zadání designu a jděte ten systém opravit.