Když se dnes v Česku ptáte, kolik stojí „AI zaměstnanec“, dostanete cenu za licenci na hlavu. Je to jediná položka, která vám přijde na faktuře, a proto se o ní mluví. Je to zároveň to nejméně vypovídající číslo z celé kalkulace — a tenhle článek je o tom, co do ní patří místo něj.
Nejlepší kotvu české debaty napsala Iva Brejlová na Lupě 10. června 2026 v průzkumu Jak drahým zaměstnancem může být umělá inteligence. Čísla odtud: u jedné firmy vyšel vývojář v roce 2024 na asi 15 € měsíčně, v roce 2026 na asi 120 € (frontendista s Figmou okolo 130 €), tedy osmi- až devítinásobný nárůst, z něhož většinu rozdílu dělá jediná položka — předplatné za 105 €. Jiná firma uvádí asi 150 $ na vývojáře a asi 20 $ na nevývojáře. Další asi 3 000 Kč na hlavu měsíčně, s interním stropem 20 000 Kč na vývojáře a nejtěžšími uživateli až 1 000 $ měsíčně. Jedna firma dává na nástroje s umělou inteligencí 30 % ročních nákladů na veškerý software. Účty za tokeny se podle téhož článku pohybují „od stovek korun po 50 tisíc měsíčně“ a agent na míru vyjde jednorázově na 50 až 800 tis. Kč. Ze světa: Stripe utratí za tokeny asi 100 000 $ denně a Uber vyčerpal roční rozpočet na umělou inteligenci za čtyři měsíce, načež zastropoval 1 500 $ na zaměstnance a měsíc.
Všimněte si, co ta čísla mají společné. Všechna jsou za licenci na hlavu nebo za paušál. A rozptyl „od stovek korun po 50 tisíc“ je v tom průzkumu ta skutečná zpráva — ne průměr, který by se z toho dal udělat.
Co jsem si naměřil u sebe
Místo odhadu jsem sáhl do lokálních logů agentní práce na jedné pracovní stanici. Vzorek: 120 session souborů, záznamy od 7. září do 5. října 2026, 713 účtovaných volání modelu. Účtované záznamy padnou jen na pět dní — ostatní dny stanice neběžela nebo se pracovalo jinde. Je to tedy spodní hranice, ne celková spotřeba.
Tokeny celkem: 88 010 250. Rozpad, který mě zajímal nejvíc:
| Kategorie | Tokeny | Podíl |
|---|---|---|
| Cache read (čtení už jednou zaplaceného kontextu) | 83 791 432 | 95,21 % |
| Cache write (1h TTL 2 651 114 + 5m TTL 1 051 471) | 3 702 585 | 4,21 % |
| Výstup — co modely skutečně napsaly | 514 781 | 0,58 % |
| Skutečně nový vstupní text za celé období | 1 452 | 0,0016 % |
To poslední číslo není chyba. Za necelý měsíc práce šlo do modelů 1 452 tokenů textu, který tam ještě nikdy nebyl — zbytek byl kontext předávaný znovu a znovu. Metered ekvivalent téhle spotřeby v cenách Claude API je 70,28 $: Opus 5 56,38 $ (80,2 %, 462 volání), Sonnet 5 11,72 $ (16,7 %, 237 volání), Opus 4.7 2,18 $ (3,1 %, 14 volání).
Jednotkou není token, ale tah
Tady je ta účetní pointa. Když si spočítáte cenu na jedno volání modelu, dostanete u Opusu 5 medián 142 909 tokenů a 0,1006 $, v devadesátém percentilu 199 940 tokenů a 0,19 $, v maximu 234 602 tokenů a 0,5148 $. Průměr přes všechny modely vychází na 0,0986 $ za volání. Jeden tah agenta je tedy poměrně stabilní položka kolem desíti centů — a obsahuje přes sto čtyřicet tisíc tokenů, z nichž drtivá většina je opakované čtení toho, co už agent zná.
Na jeden vyprodukovaný token se v mém vzorku přečetlo 171 tokenů. To není neefektivita, kterou by šlo vypnout; tak agentní práce funguje. Model při každém tahu znovu vidí zadání, historii, soubory a výsledky nástrojů. Platíte za čtení vlastního kontextu, ne za psaní.
Důsledek pro kalkulačku je přímý. Efektivní cena za milion doručených výstupních tokenů mi vyšla na 137 $. Ceníková cena výstupu Opusu 5 je 25 $ za milion. Kdo si tedy odhadne náklad jako „kolik textu chci, krát ceníková cena výstupu“, mýlí se asi 5,5krát — a mýlí se směrem dolů, což je ten nepříjemný směr. Pro úplnost ceník, proti kterému jsem počítal (ověřeno 5. října 2026): Opus 5 5 $ vstup / 25 $ výstup za milion, Sonnet 5 2 $ / 10 $, Haiku 4.5 1 $ / 5 $; cache read za desetinu ceny vstupu, cache write za 1,25násobek (5 min) nebo dvojnásobek (1 hodina).
Paušál jako anestetikum
Teď to nejdůležitější přiznání: těch 70,28 $ jsem nezaplatil. Ta práce jde z paušálního předplatného. Je to stínová cena — metered ekvivalent práce placené paušálem. A právě proto je paušál v účetnictví zrádný: schová všechno, co se pod ním děje.
Schová například tohle. Stejná práce bez promptové cache by v metered cenách stála 383,30 $ místo 70,28 $, tedy 5,45× víc. Celý ten rozdíl dělá hygiena kontextu — jak dlouho sezení žije, jak se komprimuje, jak často se cache ohřívá. Je to největší jednotlivá páka v celé kalkulaci a na faktuře za paušál ji nevidíte.
A schová rozdělení v čase. Nejdražší den vzorku (5. října) stál 50,70 $, tedy 72 % celého období, při 66 208 484 tokenech. Nejdražších 10 % volání udělalo 25,4 % nákladu. Měsíční průměr je u takhle rozdělené spotřeby bezcenný údaj; počítá se špička a chvost, protože to je to, co narazí na strop.
Mám pro to vlastní srovnání. Na skutečně metered API — to, které pálí produkční funkce mých vlastních aplikací — si držím strop 30 $ měsíčně, absolutní maximum 40 $. Tedy méně, než by v metered cenách stál jediný den mojí agentní práce. Dokud to platí paušál, nikdo to v rozpočtu neuvidí.
Položky, které do nákladu patří a nemají fakturu
Cena limitu. Dvakrát — 31. května a 25. června 2026 — mi na metered API došly kredity, respektive jsem narazil na měsíční strop. Extrakce dat modelem v jedné mojí pipeline kvůli tomu tiše stála asi pět dní, než si toho někdo všiml. Monitoring hlídal příjem dat, který běžel dál; extrakci, která padala, nehlídal nikdo. Data se neztratila, ale výstup pět dní nebyl. Účetní položka tedy není „ušetřeno X“, je to „pět dní nedodáno“. Strop není spořicí nástroj, je to tichý vypínač.
Cena opravy a kontroly. Mám případ, kdy agent nahlásil hotovou práci, která v kódu nebyla — fabrikovaný commit s hlášením „hotovo“. A případ, kdy byly tři hotové články živé na produkci, ale chyběly v gitu; odhalilo se to náhodou. Tyhle věci nechytá test, chytá je lidská kontrola, a ta kontrola je nákladová položka, jejíž cena roste s objemem výstupu agenta. Čím produktivnější agent, tím dražší kontrola — ne naopak.
Čas člověka na kontrolu. A tady končí moje data. Kolik hodin mě stojí kontrola výstupů, z logů spočítat neumím. Co by bylo potřeba měřit, vím: časové značky od okamžiku předložení výstupu po schválení nebo zamítnutí a počet kol, než výstup projde. To zatím neměřím, takže ta položka patří do rozpočtu jako výslovně nevyčíslená — ne jako nula. Nejčastější účetní lež v téhle oblasti totiž není špatné číslo. Je to položka vykázaná jako nula, protože na ni nepřišla faktura.
Srovnávací past: proč 343× není změna ceny
Táž autorka psala na Lupě 24. září 2026 o českém e-shopu, který vyměnil generativní agenty za rozhodovací model a hlásí 343× nižší náklady, zpracování z 32,4 s na 1,7 s a přesnost o 30 až 40 % výš. Ta výměna mohla být úplně správná a nemám nejmenší důvod ji rozporovat.
Metodicky je ale potřeba říct, co to číslo je. 343× není změna ceny, je to změna úlohy. Kategorizace produktů s pevným, krátkým výstupem a agentní práce s dlouhým kontextem nejsou totéž zadání — v jednom případě platíte za rozhodnutí, ve druhém za opakované čtení stavu. Cena za úlohu se smí srovnávat jen při stejné úloze a stejné akceptační laťce. Jinak se dvojnásobek i třistanásobek dá vyrobit skoro libovolně, a to v obou směrech.
Metoda na pět řádků
Tohle si můžete přepsat do vlastní tabulky:
- Paušály a licence — jediná položka s fakturou. Uveďte ji, ale nespoléhejte na ni.
- Metered tokeny — skutečná spotřeba produkčních funkcí, samostatně od agentní práce.
- Mechanika kontextu — cache read, cache write, komprimace kontextu. U mě to byl faktor 5,45×, tedy největší páka v celé kalkulaci.
- Neúspěšné tahy a opravy — volání, která nevedla k přijatému výstupu, plus práce na nápravě.
- Čas člověka na kontrolu — i když ho neumíte vyčíslit, veďte ho jako řádek.
A tři pasti, do kterých se v téhle tabulce padá nejčastěji: průměr místo špičky (u mě 72 % nákladu v jediném dni), ceníková cena výstupu jako základ odhadu (mýlí se asi 5,5krát) a položka vykázaná jako nula, protože na ni nemáte doklad.
Co z toho neplatí
Omezení jsou tři a jsou podstatná. Je to jedna pracovní stanice, ne flotila, a účtované záznamy padají na pět dní, takže je to spodní hranice. Je to metered ekvivalent práce, kterou skutečně platí paušál — čísla popisují cenu, kterou by ta práce měla, ne tu, kterou jsem zaplatil. A čas na kontrolu jsem nenaměřil, takže nejpravděpodobněji největší položka celé kalkulace v ní chybí.
Měřil jsem navíc nad vzorkem, do kterého patřila i ta session, ve které jsem počítal. Během hodiny, kdy jsem to dělal, se čísla posunula o jednotky procent. Je to snapshot, ne účetní závěrka.
A jedna věc, kterou půjde za měsíc přeměřit a která mě může vyvrátit: tvrdím, že podíl cache read zůstane nad devadesáti procenty a že rozdělení nákladu zůstane podobně nerovné — nejdražší den udělá většinu období. Jestli se za měsíc ukáže, že spotřeba je rozprostřená rovnoměrně, byl můj argument proti průměrům postavený na malém vzorku a napíšu to.