Jeg har længe haft det skidt med de pris-per-opgave-grafer, der kører i alle benchmarks lige nu. Så jeg bad om at få min egen fornemmelse efterprøvet på vores egne data:
Svaret var nej, og ikke af den grund jeg troede. Prisen pr. enhed steg på alle tre mål — fordi enheden selv voksede hurtigere, end prisen faldt. Nej-svaret er altså et symptom, ikke en dom: i et rigtigt projekt står opgaven aldrig stille længe nok til, at man kan sætte en pris på den.
Hvad der faktisk blev målt
Alle sessionsfiler fra februar til oktober 2026: 14.243 JSONL-filer, 366.966 afregnede API-kald. Hvert kald prissat til den enkelte models egen listepris.
Der er én fælde i det regnestykke, som er værd at kende, hvis du selv prøver. Claude Code skriver én linje pr. indholdsblok i svaret, og hver linje gentager hele svarets usage. Tæller man dem naivt sammen, overtæller man med en faktor 2,5. requestId tildeles én gang pr. forespørgsel — altså én gang pr. regning — så det er den, man deduplikerer på.
Det svære er ikke at tælle kronerne. Det er at finde ud af, hvad man skal dele dem med. "Pris pr. opgave" kræver en opgave, og vi har ikke to ens. Så jeg målte arbejdet på tre måder, der hver især kommer fra sit eget system — tre uafhængige kilder, der ikke kan svinge i takt med regningen ved et tilfælde:
- Menneskeprompts — hvor mange gange et menneske faktisk skrev noget, fra promptloggen
- Commits — feat- og fix-commits på tværs af rodrepo og alle submoduler, fra git
- Timer ved rattet — timer hvor mindst én agent kørte, fra agent-timer-opgørelsen
Hvis prisstigningen bare var en måleartefakt, skulle de tre skilles ad. Det gør de ikke:
Fra marts til august blev en commit 9,3 gange dyrere, en time ved rattet 5 gange dyrere, og en prompt 7,5 gange dyrere.
Marts er basislinje. September og oktober er med i graferne, men jeg regner dem ikke med, og grunden er forskellig for hvert mål: prompt-filteret kasserer 62 % af oktobers prompts mod 9 % af marts’, så nævneren bliver kunstigt lille, og en del af oktobers commits var slet ikke skrevet endnu, da jeg målte. Timerne ved rattet er det mest robuste af de tre — det tal er bare støjende på en måned med 124 timer i stedet for 356.
Hver instruktion køber meget mere maskinarbejde
En prompt i marts udløste godt tusind output-tokens. En prompt i august udløste fjorten tusind. Faktor 12 fra marts til august.
Vi har ikke gjort opgaverne billigere. Vi har fået hver instruktion til at bære meget mere.
En del af det er en indstilling, vi selv har skruet op. Fra juli bad vi modellen tænke grundigere på næsten alt (effort: high), og fra august kan jeg se, hvor meget af outputtet der er modellens tænkning frem for leveret tekst: 32 % i august, 29 % i oktober. Feltet findes ikke i data før august, så andelen i marts er ukendt — men retningen er ikke til at tage fejl af.
Vi gik op ad modelstigen, ikke ned
Hvis vi var blevet billigere pr. opgave, skulle det vise sig som en billigere modelkurv.
Det modsatte skete. Marts kørte en femtedel af sit output på haiku; oktober kører på opus og fable, og fable-5-1 er den dyreste model i prislisten — 50 dollar pr. million output-tokens mod haiku-4-5's 5.
Den gennemsnitlige enhedspris blev dog kun fordoblet, ikke tidoblet. Det er den ene ting i hele datasættet, der peger den anden vej: priserne inden for familierne faldt undervejs. Opus kostede 5 dollar pr. million input-tokens og 25 pr. million output-tokens i foråret; i efteråret 4 og 20. Vi fik altså en del af nedsættelsen — den forsvandt bare i, at vi samtidig flyttede opad.
En sidste ting, som er stor, men som ikke beviser noget om os: caching. Mellem 95 og 98 % af alle input-tokens leveres som cache-læsninger til en brøkdel af input-prisen. Input-siden kostede 255.000 kroner; uden caching ville den have kostet 1,69 millioner. Faktoren er bare flad hele vejen — den står på det samme fra marts til oktober. Sådan virker agentiske løkker af sig selv — det er produktets arkitektur, ikke noget vi har opnået.
Hvorfor spørgsmålet ikke kan stilles
"Pris pr. opgave" kræver, at opgaven holdes konstant. Det har vi aldrig gjort, og det kan efterprøves. Jeg klyngede alle 38.306 prompts på deres normaliserede åbningssætning for at finde opgaver, vi havde gentaget over tid. Der kom ni klynger ud, som spænder over tre måneder eller mere. Alle ni er slash-kommandoer og boilerplate — /model, /compact, kontekstfortsættelser. Ikke én reel opgave er gentaget.
Vi har ti kørsler af den samme designopgave liggende, og de er faktisk sammenlignelige — men de ligger alle inden for to uger i maj. De måler promptændringer, ikke tid.
Det rammer også vores egne tal. Den samme instruktion køber i dag et tolv gange længere autonomt forløb end i marts, så en kurve hen over de otte måneder stiller to forskellige ting op ved siden af hinanden og kalder dem det samme.
I et rigtigt projekt sidder man ikke og kører de samme opgaver af igen og igen. Otte måneder i et rigtigt projekt ser derfor sådan ud: alt bliver dyrere pr. enhed, fordi enheden bliver ved med at vokse.
Den uvidenskabelige del
Så er der det, jeg ikke kan måle, men godt kan mærke: gennem månederne føles det bare som om det kører bedre og bedre, mere autonomt, med færre fejl.
Den første halvdel af den fornemmelse har faktisk et tal under sig. "Mere autonomt" passer i hvert fald med grafen over output pr. prompt — hver instruktion køber et længere forløb, hvor jeg ikke skal gribe ind. Fornemmelsen og målingen peger samme vej.
Den anden halvdel kan jeg ikke bakke op. Jeg prøvede: hvis der kom færre fejl, burde andelen af fix-commits falde.
Den falder fra 45 % i marts til 30 % i juli — og ryger så op på 54 % i september igen. Der er ingen retning at hænge en påstand på. Og en fix-commit er i øvrigt ikke det samme som en agentfejl; den kan lige så godt rette noget, et menneske skrev i 2025.
Så "færre fejl" står som det, det er: min oplevelse, ikke et resultat. Jeg skriver det med, fordi det er ærligt, og lader være med at pynte det med et tal, der ikke bærer.
Benchmarket har ret — det måler bare noget andet
Jeg skal være fair over for de grafer, jeg startede med at brokke mig over. Et benchmark, der kører den samme opgave igen og igen, kan faktisk svare på, om den opgave er blevet billigere. Det er et rimeligt spørgsmål, det er et ordentligt målt tal, og svaret er formentlig ja. Der er ikke noget galt med det.
Det tal kan bare ikke flyttes over i dit eget budget. For i et rigtigt projekt sker der tre ting på én gang, og de trækker alle sammen den anden vej:
- Opgaverne bliver større. Den samme instruktion køber tolv gange mere maskinarbejde end i marts.
- De kører længere. Et forløb, jeg før skulle gribe ind i undervejs, kører nu til ende af sig selv. Det er den samme måling som ovenfor set fra en anden vinkel — jeg kan ikke skille de to ad i data.
- Flere af dem kører samtidig. For hver klokketime med mindst én agent i gang kørte der i marts 1,3 agent-timer. I august var det 2,4.
Alle tre er direkte konsekvenser af, at modellerne er blevet bedre — og alle tre koster flere tokens, ikke færre. Gevinsten havner aldrig på bankbogen. Den bliver sat i arbejde med det samme.
Så en faldende pris pr. opgave betyder ikke en faldende AI-regning. Hos os er det nærmest det modsatte: 506 kroner i februar, 75.222 i juli, 294.167 i alt fra februar til oktober. Jo bedre modellerne bliver, jo mere giver vi dem.
Hvad tallene ikke dækker
For en god ordens skyld, fordi det ændrer, hvor hårdt man kan trække på dem:
- Prompt-tallet er skrøbeligt. Maskingenererede prompts filtreres fra, og filteret fjerner 9 % i marts mod 62 % i oktober. Fejl i det filter rammer trenden skævt.
- Oktober-commits er undertalte. En del af oktobers arbejde var ikke committet endnu, da jeg målte.
- Arbejde flyttet til andre værktøjer er usynligt her. Det her er Claude Code-sessioner, ikke alt arbejde.
- Tænkningsandelen før august kan ikke genskabes. Feltet blev først skrevet fra august.
Prisen pr. opgave kan godt falde i et benchmark. Regningen gør det ikke.