2026 márciusa és júliusa között François‑Xavier Martin egy autónóm szoftverfejlesztési életciklus‑keretrendszerrel (az első generációval) gyártott egy 861 601 soros alkalmazást a Claude Code rendszerrel. Az első generáció viszont nem tárolta a használati adatokat, a rendszer alapértelmezett 30 napos átírás‑megőrzése pedig törölte a fennmaradó feljegyzéseket, ezért az eredeti költségszámla elveszett.
A cikk fő adatbázisa egy későbbi, mérőeszközökkel felszerelt második generációs „gyár” futtatásából származik: a claude‑code‑config keretrendszer maga rögzíti minden szakasz token‑felhasználását (input, output, cache read, cache write), költségét, modelljét és hibakategóriáját egy ledgerben. A vizsgált adathalmaz egyetlen repository minden történeteit fedi le 2026. június 25. és július 18. között: 17 futás, 193 story‑build, 374 szakaszkísérlet és 336 munkamenet‑log szerepel benne.
A júniusi futások Claude Opus 4.8‑at, a júliusiak Claude Fable 5‑öt használták; a kisebb részeket Claude Haiku 4.5 kezelte.
Mit értünk story‑on és story‑buildön
A cikkben a „story” az agilis artefaktum: egy epikből lebontott, elfogadási kritériumokkal ellátott követelmény, amelyre az ügynök befejezési feltételt kap. A „story‑build” egy story teljes automatizált leszállítási ciklusa: tesztek írása (TDD jelleggel), build, coverage‑gate, dedikált review‑ügynök általi felülvizsgálat és merge, beleértve a hibajavításokat és a megismételt kéréseket, amikor egy ügynök válasza hibás.
A futtatás egyszerre legfeljebb öt story‑t tartott "in flight" izolált git worktree‑kben.
Mennyibe került egy story (mérleg és számok)
A gyár 595.7 millió tokent fogyasztott 77 leszállított story szállításához, ami 7.7 millió token/storynak felel meg. Az Anthropic futtatási listaárakon átszámítva ez összesen 837.53 USD‑nek felel meg, vagyis 10.88 USD/story. A számláló minden elpazarolt tokent, az öt FAILED storyt, a 22 sikertelen szakaszkísérletet, a hibajavító és újrakérő ciklusokat és a retry‑okat is tartalmazza; a nevező csak a leszállított storyk számát veszi figyelembe.
Korábbi becsléseiben a szerző „néhány dollártól néhány tíz dollárig” jelezte a story költségét; a mérés azt adja, hogy az értékek 3.02 és 43.24 USD között mozognak, medián 9.56 USD. A legdrágább story 43.24 USD volt (egy 3‑pontos történet, amely review retryt és hibajavító ciklust ért). Az óra szerinti átlag közel kétszer és félszer nagyobb a mediánnál, mert egy éjszakai futás kétszer is a szolgáltatói rate‑limit miatt megállt és órákig várakozott — ez számlázási artefaktum volt, nem az ügynököké.
A szerző megjegyzi, hogy a korábbi „szellemalkalmazás” 696 storyja körülbelül 5.4 milliárd token fogyasztást jelentene ugyanilyen arányok mellett, de ezt soha nem fogjuk megtudni, mert az eredeti logok elvesztek.
A gyár elsősorban olvasó‑gépként működik
A mérés nagy tanulsága, hogy a tokenforgalom döntő része cache‑olásból származik: a teljes tokenfelhasználás 95.4%-a cache read volt. A gyár nagyjából 73 cache‑olva elolvasott tokenre jutólagosan ír vagy fogad egy új tokent. A cache‑rendszer miatt egy cache‑read árban körülbelül tizede egy friss inputnak, viszont új tartalmat írni a cache‑be prémiumdíjjal jár.
Bár a cache write‑ok csak 3.3%‑át adják a tokeneknek, a számla 31.2%‑áért felelősek; a cache‑forgalom összességében 77%‑át viszi el a költségnek. A friss input költsége csupán 1.6%.
Ugyanezt a mintát három független mintában látta: a gyári futásokban, interaktív keretfejlesztési sessionökben és a „szellem” megmaradt töredékeiben — tehát úgy tűnik, ez az ügynökös fejlesztés token‑fogyasztásának általános jellege.
Gyakorlati következmény: az ügynökalapú pipeline költségoptimalizálása elsősorban cache‑kezelés, nem pedig prompt‑rövidítés. Kontekstus‑fegyelem, cache‑réteg‑tudatosság és olyan orchestratorok, amelyek nem tömörítik túl a saját ablakukat, mozgatják meg a számlát.
A „tisztességes” nevező: hibák és újramunka
Kétféleképpen olvasható a hibaarány: a szűk értelmezés szerint a FAILED‑nek jelzett kísérletek az össz fogyasztás 5.0%-át viszik el. A „becsületes” olvasat, amely magában foglalja az összes újramunkát — retryok, bugfix‑ és re‑ask‑ciklusok, valamint a közben lehalt munkamenetek által kiküldött tokeneit — körülbelül 13%‑ot képvisel. Sok nyilvános költségkimutatás nem tisztázza melyik olvasatot használja.
A 76 mérhető story közül csak 34 volt tiszta első futásra, de az újramunka viszonylag olcsó, mert a retryok kisebbek, mint a teljes build. A szerző ezt a 13%-ot a minőség „számlájának” tekinti, mert a kapuk elkapják a problémákat.
A mérőeszköz hibája és az auditálás szükségessége
Az elemzés során a szerző egy hibát talált: a ledger a valós fogyasztás hatodát hiányosan rögzítette, 694.65 USD‑t könyvelt, míg a session logok 837.53 USD‑t mutattak. A probléma oka, hogy amikor egy eredmény‑envelope nem ment át validáción, a controller re‑ask művelete felülírta az eredeti szakasz sorának használati adatait, így a drága, sikertelen munkamenet eltűnt a könyvelésből; a közben lehalt munkamenetek pedig soha nem írták vissza magukat. 57 kísérlet volt érintett, ezért a session logok szolgálnak a földi igazságnak.
A mérőrendszer auditálásra szorult, ezért a szerző hibajegyet nyitott a saját gyára ellen, amely három hibára bomlott szét és kijavította az overwrite‑ot és a modell‑rögzítést egy összevont PR‑ben (issue #480, PR #482, 3 200 teszt sikeresen futott). A gyár így önmaga auditálta és javította többnyire a saját számlálóját; a lezuhant munkamenetekből történő költségvisszanyerés munkája nyitott feladat maradt.
Ki fizet valójában?
A tényleges marginális számla nulla volt: a szerző egy havi 200 USD‑s Max 20x előfizetést használ, ezért minden dollár itt API‑egyenértékesített érték. Az előfizetés valójában kvótát ad, nem kizárólag pénzt. Az éjszakai futás kétszer megállt az ötórás rate‑limit ablak miatt, és tíz dispatch 3.3–4.2 órát várt újraindulásra. Egy fix havi díj esetén az idő az, ami korlátozza a felhasználást.
Egy gördülő hónap mért munkája mindhárom kódbázison összesen körülbelül 1 088 USD API‑egyenértéket tett ki a 200 USD díjhoz képest — több mint ötszörös arány, és ez alsó becslés, mert a régebbi átírások törlődnek. Ez egy árszembenállást bizonyít a listaárakkal: a listaár nem feltétlenül az Anthropic költsége, hanem azok árrését is tartalmazza.
A jelenlegi fogyasztói/Team szerződés‑különbségek inkább szerződéses és kezelési különbségek: a Team prémium ülés (125 USD) üzleti feltételeket és központi adminisztrációt ad, de nagyjából fele‑kvótát ad dolláronként. A sávok és kvóták később szigorodhatnak; aki mér, észreveszi a napot, amikor a kereskedelem megváltozik; aki nem mér, csak lassabbnak és szegényebbnek érzi magát, anélkül hogy tudná miért.
Mit változtat a mérés
Elemzés közben kiderült, hogy minden mérést model‑routing kikapcsolt állapotában készítettek: mechanikus merges prémium‑model árakat égettek el Haiku‑szintű munkáért, ami az összes token 12.3%-át tette ki. Így a 7.7 millió token/delivery arány nem optimalizált állapotot tükröz. A cikkben felfedezett bug javítása már a gyár backlogjában van.
Második megállapítás: a szerző saját interaktív definiálási munkái — epikek és storyk írása a gyár specifikációjához — körülbelül 190 millió tokent fogyasztottak, ami nagyjából 25 storynyi munkának felel meg (~160 USD API‑egyenértékben). Amikor a megvalósítás relatíve olcsó, maga a kód már nem a legdrágább elem: a különbség a 10.88 USD/story (amit a mért pipeline számolt) és az ismeretlen költségű 861 601 sor között az, hogy az egyik pipeline feljegyezte a számlát.
Összefoglalás
- Egy helyben mért, agent‑vezérelt kódfeldolgozó gyárnál a tokenforgalom túlnyomó része cache‑olásból származik, és a cache‑forgalom döntően befolyásolja a költséget.
- A mérési rendszer hibái jelentősen alá‑ vagy felülbecsülhetik a költséget, ezért a mérőeszköz auditja létfontosságú.
- Az előfizetéses kvóta‑modell és a valódi listaár közti különbség miatt a valós ráfordítás gyakran eltér a listáron számolt összegektől.
- Költségoptimalizálásnál a prompt‑rövidítés helyett a cache‑kezelés és az orchestration szemlélet számít.
A gyár és a repository (claude‑code‑config és local‑code‑bench) nyilvánosak; a módszertan, a CSV‑k és az adatkinyerő script elérhetők, így minden szám ellenőrizhető a szerző munkája alapján. A teljes produkciós alkalmazás, amelyről a cikk elején szó volt, továbbra is privát, ezért az csak kísértetként szerepel az elemzésben.
