Nejlevnější AI agent není ten s nejnižší cenou za token. Rozhoduje celá práce

Cena coding agenta se dnes často prodává jako jednoduché číslo za milion tokenů. Jenže firma nekupuje tokeny. Kupuje dokončenou práci: přečtený repozitář, správně upravené soubory, proběhlé testy a výsledek, který někdo nemusí půl dne opravovat. Čerstvá rychlá zpráva o benchmarku Positu ukazuje, proč je právě tahle změna pohledu důležitější než další tabulka s cenou API.

Posit ve svém vlastním srovnání tvrdí, že Posit Assistant zvládl vybrané úlohy podobně dobře jako Claude Code a Codex, ale s nižšími celkovými náklady. Neznamená to, že vyhrál univerzální závod všech coding agentů. Znamená to něco praktičtějšího: levnější model nebo levnější token nemusí být levnější práce, pokud musí agent kolem každého kroku vyrábět zbytečné mezikroky.

Tokeny vypadají přesně. Celý úkol je důležitější

Cena tokenu je pro nákupní tabulku pohodlná. Dá se porovnat, zaokrouhlit a poslat do prezentace. Jenže v reálném vývoji se účet skládá také z počtu kol mezi agentem a nástroji, z délky systémových instrukcí, z opakovaných pokusů, z čekání na testy a z času člověka, který musí výsledek zkontrolovat.

Představme si dvě cesty ke stejnému cíli. První agent dostane úkol, přečte relevantní soubory, upraví kód a odevzdá změnu. Druhý nejdřív napíše pomocný skript, uloží výstup do dočasného souboru, znovu ho načte, několikrát si nechá vysvětlit stav prostředí a nakonec udělá stejnou práci. Druhý nemusí být horší model. Může mít jen dražší pracovní prostředí.

Právě proto má smysl mluvit o hodnocení AI agentů jako o měření celého procesu, ne pouze o správnosti jedné odpovědi. Firma by měla vědět, kolik stojí dokončený úkol, kolik pokusů skončí opravou, jak dlouho trvá lidské review a kolik práce vznikne kolem neúspěšného běhu.

Positův benchmark měří práci, ne reklamní slib

Posit použil vlastní benchmark bluffbench2, který zkouší, zda coding agent při průzkumné analýze dat odhalí nenápadné problémy v datech a vizualizacích. To je jiný typ úlohy než otázka „napiš funkci“. Agent musí pracovat s prostředím, prohlížet výsledky a všimnout si něčeho, co není na první pohled nápadné.

Čísla pocházejí přímo z Positova článku a vztahují se ke konkrétním verzím modelů a konkrétnímu nastavení. Kompletní evaluační logy jsou zveřejněné samostatně. „Console“ znamená přístup k trvalé relaci R přes MCP, zatímco „shell only“ znamená práci přes skripty. Tabulka proto není ceník předplatného ani obecný žebříček modelů. Je to měření toho, kolik stojí určitá práce v určitém pracovním prostředí.

Na nejzajímavějším řádku není samotných 6,76 dolaru. Důležitý je poměr mezi výsledkem a cestou k němu. Claude Sonnet 5.5 v Posit Assistantu dosáhl v tomto testu stejného skóre jako shellová varianta Claude Code, ale za nižší celkovou cenu. To je přesně ten typ rozdílu, který v běžném srovnání ceny tokenů neuvidíte.

Druhý test ukázal, kde končí silná interpretace

Posit přidal také úlohy z DeepSWE 1.1, tedy náročnějšího benchmarku dlouhých softwarových úkolů. V jedné konfiguraci zvládl Posit Assistant s Claude Sonnet 5.5 24 ze 34 úloh při ceně 12,72 dolaru, zatímco Claude Code zvládl 17 ze 34 za 13,20 dolaru. S GPT 6.1 Sol byl rozdíl opačnější: Posit Assistant dokončil 25 ze 34 úloh, Codex 27 ze 34, ale Posit Assistant vyšel levněji.

Tady je nutné reklamní tón Positu přibrzdit. Autoři testovali pouze pythonové úlohy, použili jeden průchod a jen omezený počet konfigurací. Sami píší, že rozdíly nejsou statisticky rozlišitelné od šumu. Výsledek tedy nepodporuje tvrzení, že Posit Assistant porazil Claude Code nebo Codex ve vývoji softwaru. Podporuje skromnější závěr: v tomto omezeném měření nebyl výrazně horší a v některých bězích stál méně.

To je mimochodem zdravější způsob, jak číst firemní benchmark. Ne jako rozsudek nad celým trhem, ale jako účetní doklad k jedné sadě úloh. Kdo z něj udělá univerzální vítězství, přidává do výsledku vlastní marketing, který v původním měření není.

Levnější práce vzniká v harnessu, ne jen v modelu

Posit vysvětluje rozdíl mimo jiné tím, jak je agent napojený na nástroje. Posit Assistant má persistentní relaci R nebo Pythonu a může dostat výsledek přímo. Claude Code nebo Codex bez podobného prostředí musí někdy napsat skript, uložit graf jako soubor a následně ho znovu načíst. Model tak utrácí tokeny za provozní okliku, která s datovou otázkou sama nesouvisí.

To je práce pro agent harness: vrstvu, která spojuje model s nástroji, stavem úkolu, soubory, testy a pravidly pro zastavení. Dva týmy mohou používat stejný model a přesto dostat jinou cenu i jiný výsledek, protože jeden agent má dobře připravené rozhraní a druhý se v prostředí pohybuje jako návštěvník bez mapy.

Posit uvádí také kratší systémové instrukce, paralelní provádění nezávislých akcí, omezení zbytečně dlouhých výstupů a lepší cacheování promptů. Každá z těchto úprav sama o sobě vypadá jako technický detail. V dlouhé relaci se ale technické detaily násobí. O několik tisíc tokenů kratší úvod, jedno méně opakované čtení a jeden paralelní krok mohou změnit účet za celý úkol.

To má nepříjemný důsledek pro nákupčí AI. Nestačí se zeptat, který model je nejlevnější. Musí se ptát, jaké nástroje agent skutečně používá, co vidí v každém kroku, kolik dat dostává znovu, jak se chová při chybě a zda se jeho práce dá přerušit bez ztráty stavu.

Nejdražší běh je ten, který skončí skoro hotový

V tabulce Positu jsou náklady vyjádřené v dolarech za běh benchmarku. Ve firmě ale vzniká ještě druhý účet. Agent může dokončit devadesát procent práce, špatně upravit jeden soubor a přinutit člověka projít celý diff znovu. Může také vyrobit výsledek, který projde testy, ale neřeší původní problém.

Přesně tady navazuje zkušenost popsaná v dřívějším článku o coding agentech a CI. Když změny vznikají rychleji, může se bottleneck přesunout do testů, review nebo rozhodování, co se vlastně smí sloučit. Levnější generování pak samo o sobě nepřinese levnější vývoj. Jen vytvoří více materiálu, který někdo musí zpracovat.

Stejnou hranici ukázal i rozbor růstu agentního programování na GitHubu. Počet změn, commitů nebo pull requestů je aktivita, nikoli hodnota. U nákladů platí totéž: nízký účet za model není úspora, pokud se zbytek práce přesune na dražší lidskou kontrolu.

Firmy by měly měřit cenu dokončení, ne cenu modelu

Praktická otázka pro tým proto nezní „kolik stojí milion tokenů?“. Zní: kolik stojí bezpečně dokončený typický úkol od zadání po merge? Do odpovědi patří model, nástroje, opakované běhy, infrastruktura, čekání na testy i review. Pokud se některá část nedá změřit přesně, je lepší ji přiznat jako neznámou než předstírat, že cena API představuje celý účet.

Tým by měl zvlášť sledovat cenu prvního pokusu, cenu opravy, podíl úloh dokončených bez ručního zásahu a čas, který člověk tráví ověřováním. U citlivých změn je důležitá také cena chyby: oprava rozbitého testu není totéž jako špatná migrace databáze, zveřejněný klíč nebo změna, kterou nikdo několik týdnů neodhalí.

Takové měření je méně efektní než žebříček modelů. Zároveň je mnohem blíž rozhodnutí, které firma skutečně dělá. Nekupuje si abstraktní schopnost generovat kód. Kupuje si rychlejší a kontrolovatelnější průchod konkrétní prací.

Cena za token je vedlejší číslo

Positův text není důkazem, že jeden coding agent je nejlepší pro všechny. Je ale dobrým připomenutím, že model s levnějším tokenem nemusí být levnější nástroj a model s dražším tokenem nemusí být dražší úkol. Rozhoduje, kolik zbytečných kroků prostředí vynutí, jak dobře agent vidí výsledek své práce a kolik kontroly zůstane na člověku.

Budoucí srovnání agentů by proto měla vedle skóre uvádět i cenu dokončeného úkolu, počet opakování, rozsah lidského review a podmínky prostředí. Bez toho srovnáváme jen jednu část výrobní linky a tváříme se, že známe cenu celého produktu.

Nejlevnější AI agent není ten, který spotřebuje nejméně tokenů. Je to ten, který za rozumný účet dovede práci do ověřitelného konce — a přitom nenechá člověka uklízet škody, které se do benchmarkové tabulky nevešly.