Het onderwerp van dit stuk is aangedragen door een taak die ik zelf niet meer draai. Elke ochtend gaat er een scan langs de Anthropic-changelog, de docs en een paar nieuwsbronnen, kijkt of er iets tussen zit dat mijn werk verandert, en legt hooguit drie voorstellen voor. Ik lees de uitkomst op mijn telefoon en kies er een. Zo is dit artikel begonnen.
Wat ik van die taak nooit heb geweten, is wat hij kost. Hij draait, hij levert iets op, en verder was hij een regel in een configuratiebestand. Sinds Claude Code 2.1.243 staat er een Loops-blok in /usage, en daar staat per terugkerende taak hoe vaak hij vuurt, hoe vaak hij gedraaid heeft, hoeveel tokens dat kostte in totaal en per run, en wanneer hij voor het laatst is gegaan. Voor het eerst hangt er dus een getal aan het werk dat ik heb weggeautomatiseerd.
Over dat wegautomatiseren schreef ik eerder in het stuk over loops en herhaalwerk. Toen ging het over de vraag welk werk zich zo vaak herhaalt dat het niet meer bij jou hoort. Deze keer gaat het over de rekening die daarna doorloopt.
Drie regels in dezelfde release
Er zitten drie dingen in 2.1.243 die allemaal over hetzelfde gaan, namelijk over de vraag waar je kostencijfer vandaan komt.
| Wat | Wat het doet | Voorwaarde |
|---|---|---|
Loops-blok in /usage | Een regel per terugkerende taak, gesorteerd op totaal tokens, met runs, totaal, tokens per run en laatste run | Claude Code 2.1.242 of nieuwer |
promptCacheTtl en subagentPromptCacheTtl | Kies zelf de levensduur van de prompt-cache, apart voor het hoofdgesprek en voor alles daarbuiten | Claude Code 2.1.242 of nieuwer, waarde 5m of 1h |
modelPricing | Laat /cost en de statusregel rekenen met de contractprijs van je organisatie in plaats van de lijstprijs | Beheerde instelling, alleen via managed settings |
De eerste is de meter. De tweede is een knop waar de meter je naartoe stuurt zodra je hem hebt gelezen. De derde repareert iets waar bijna niemand bij stilstaat, namelijk dat het dollarbedrag in /usage lokaal wordt uitgerekend tegen standaard lijstprijzen. Dat cijfer weet niets van je kortingen en niets van een actieprijs, en volgens de documentatie kan het daarom afwijken van je echte factuur. Wie een contract met korting heeft, keek dus naar een getal dat structureel te hoog stond. Wie op een abonnement zit, kijkt naar een getal dat voor de facturering helemaal niet relevant is.
Waarom een dagelijkse taak nooit een warme cache heeft
De interessantste van de drie is de cache-instelling, en wel omdat hij voor mijn scan precies de verkeerde kant op wijst.
De prompt-cache werkt op het begin van je verzoek. Claude Code stuurt elke beurt de hele context opnieuw mee, en de API kijkt of het begin daarvan overeenkomt met iets dat hij net verwerkt heeft. Die vergelijking is exact, dus een wijziging ergens vooraan zet alles wat erachter staat opnieuw aan het rekenen. Daarom staat wat zelden verandert vooraan: eerst de systeemprompt met de tooldefinities, dan de projectcontext uit CLAUDE.md, en pas daarna het gesprek zelf.
Zo’n cache-ingang vervalt na een periode zonder activiteit, en elk verzoek dat hem raakt zet de klok terug op nul. De API kent twee levensduren. Vijf minuten is de standaard voor wie met een API-sleutel of via een cloudprovider werkt. Een uur houdt de cache warm over een langere pauze, en daar hangt een prijskaartje aan: een schrijfactie in de cache van vijf minuten kost 1,25 keer de basisprijs voor invoer, in de cache van een uur 2 keer, en teruglezen kost 0,1 keer. Voor Sonnet 5 is dat 2 dollar per miljoen tokens basis, 2,50 voor de korte schrijfactie, 4 voor de lange, en 20 dollarcent om te lezen.
Zet die twee dingen naast elkaar en mijn scan valt er buiten. Hij draait een keer per etmaal. Het gat tussen twee runs is vierentwintig uur, dus de cache is bij de volgende run altijd koud, of ik nu vijf minuten of een uur heb ingesteld. Wat de langere levensduur me oplevert, is precies niets. Wat hij me kost, is het verschil tussen 2,50 en 4 dollar per miljoen tokens, elke ochtend opnieuw, op een prefix die niemand ooit terugleest. De documentatie zegt het in één zin. De langere levensduur kost meer bij werk dat nooit langer dan vijf minuten stilvalt, want daar geldt het hogere schrijftarief zonder dat je iets aan de langere houdbaarheid hebt. Mijn scan is de spiegel daarvan. Hij valt zo lang stil dat zelfs het uur niet helpt.
De instelling is er dus voor iets anders, namelijk voor een lange werksessie met pauzes erin, waar je na een half uur koffie terugkomt in hetzelfde gesprek. Voor terugkerende taken die ver uit elkaar liggen is 5m de goedkoopste keuze, en dat is toevallig ook de standaard.
Er zit nog een tweedeling in die het waard is om te noemen. De twee instellingen dekken twee emmers. Het hoofdgesprek zijn je interactieve beurten, je -p-runs en de Agent SDK. Alles daarbuiten zijn de subagents, de workflows, de compactie en de sessietitels. Op een abonnement binnen je plan-usage krijgt het hoofdgesprek standaard al een uur en de rest vijf minuten. Ga je over je limiet heen en trekt Claude Code usage credits aan, dan zakt het hoofdgesprek terug naar vijf minuten omdat je vanaf dat moment zelf betaalt.
Het cijfer dat de meter niet geeft
Ik heb nog geen getal voor mijn eigen scan, en dat is geen luiheid.
Het Loops-blok rekent over de lokale sessiegeschiedenis van deze machine. Werk vanaf een ander apparaat telt niet mee, werk via claude.ai ook niet, en de docs noemen de cijfers zelf bij benadering. De weergave kent twee vensters, de laatste 24 uur en de laatste 7 dagen. Een scan die net op deze versie is gaan draaien heeft dus nog geen week aan runs staan waar een gemiddelde uit te halen valt.
Wat ik wel weet uit dezelfde documentatiepagina, is de orde van grootte waar Anthropic zelf mee rekent voor een ontwikkelaar: gemiddeld ongeveer 13 dollar per actieve dag en 150 tot 250 dollar per maand, waarbij 90 procent van de gebruikers onder de 30 dollar per actieve dag blijft. Dat is een gemiddelde over enterprise-deployments zonder vermelde steekproef, dus het zegt iets over de schaal en weinig over mijn scan. Ik zet het erbij omdat het de enige publieke referentie is die ik heb, niet omdat het mijn getal vervangt.
De kanttekening
De meter komt na de gewoonte. Mijn scan draait sinds 10 augustus en er bestond pas op 25 augustus een regel over in /usage. Dat is de volgorde waarin dit gereedschap zich ontwikkelt. Eerst kun je iets automatiseren, daarna pas zie je wat het doet. Wie in die tussenperiode een loop is vergeten, heeft niets gemerkt en krijgt ook geen correctie achteraf. De rem die er wel is, is dat een terugkerende taak in een sessie na zeven dagen zichzelf opruimt.
Een cijfer stuurt gedrag, ook de verkeerde kant op. Zodra ik weet wat een run kost, ga ik hem korter maken. Maar de reden dat deze scan dagelijks draait is dat een stille dag anders een onderwerp laat wegvallen, en die uitgave kan het tokengetal niet verantwoorden. De redactionele waarde van een run die niets vindt is precies nul in de meter en niet nul in de praktijk. Een meter die maar één ding kan meten, maakt van dat ene ding het criterium.
De tweedeling in de cache beloont het verkeerde ontwerp. Standaard krijgt het hoofdgesprek de lange levensduur en alles daarbuiten de korte. Dat betekent dat lang doorpraten in één sessie voordeliger uitpakt dan werk naar subagents duwen, terwijl dat laatste juist de manier is om context schoon te houden en om een oordeel door iemand anders te laten vellen dan degene die het geschreven heeft. Je kunt het rechtzetten met subagentPromptCacheTtl, maar de standaardwaarde is wat de meeste mensen houden.
Wat ik zelf doe
Ik laat promptCacheTtl met rust. Deze scan haalt geen voordeel uit een langere levensduur en de standaard van vijf minuten is voor hem de goedkoopste stand.
Ik ga wel het Loops-blok lezen zodra er een week aan runs op staat, met het weekvenster en niet het dagvenster, want een dagvenster laat bij een dagelijkse taak precies één run zien. Het getal dat daaruit komt zet ik in dit artikel, en niet eerder.
En ik verplaats geen enkele redactionele controle naar een model. De zes gates die de build hier blokkeren zijn node-scripts zonder token-verbruik: de cadans tussen publicaties, hergebruikte zinnen, de kanttekening in AI-stukken, de herkomst van de cover, de slop-patronen en de getallen tegen de bronbundel. Een controle die deterministisch kan zijn, hoort geen meter nodig te hebben.
Veelgestelde vragen
Heb ik iets aan een cache van een uur als mijn taak elke dag draait?
Nee. De cache-ingang vervalt ruim voordat de volgende run begint, dus je leest hem nooit terug. Je betaalt wel het hogere schrijftarief van 2 keer de basisprijs in plaats van 1,25 keer. Voor terugkerende taken met een lang gat ertussen is 5m de juiste stand.
Klopt het bedrag dat /usage mij laat zien?
Alleen als je de lijstprijs betaalt. Claude Code rekent het bedrag lokaal uit tegen standaardtarieven en weet niets van kortingen, contractprijzen of een tijdelijke actieprijs. Met de nieuwe beheerde instelling modelPricing kan een organisatie haar eigen tarieven laten gebruiken. Voor de echte facturering blijft de usage-pagina in de Console de bron.
Waarom staat mijn loop niet in het Loops-blok?
Drie mogelijke redenen. Je draait een versie ouder dan 2.1.242. Je taak zit niet bij de zwaarste en valt onder het aantal dat samengevat wordt geteld. Of je hebt hem op een andere machine gedraaid, want de cijfers komen uit de lokale sessiegeschiedenis en tellen andere apparaten of claude.ai niet mee.
Bronnen
- Claude Code CHANGELOG, versies 2.1.242 tot 2.1.245 (geraadpleegd 25 augustus 2026) — https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
- Claude Code docs, “Manage costs effectively” (geraadpleegd 25 augustus 2026) — https://code.claude.com/docs/en/costs
- Claude Code docs, “How Claude Code uses prompt caching” (geraadpleegd 25 augustus 2026) — https://code.claude.com/docs/en/prompt-caching
- Claude Code settings reference,
promptCacheTtlensubagentPromptCacheTtl(geraadpleegd 25 augustus 2026) — https://code.claude.com/docs/en/settings-reference - Claude API docs, prompt caching en prijzen (geraadpleegd 25 augustus 2026) — https://platform.claude.com/docs/en/build-with-claude/prompt-caching
Gecontroleerd op 25 augustus 2026. De drie changelog-regels heb ik bij de primaire bron nagelezen, en de cache-tarieven en de standaardwaarden staan in de documentatie van Anthropic zelf. Twee dingen kon ik niet verifiëren. modelPricing staat op deze datum in geen enkele documentatiepagina, alleen in de changelog, dus ik heb de werking niet kunnen naslaan en ook niet kunnen uitproberen zonder organisatie met een contractprijs. En mijn eigen tokencijfer ontbreekt, omdat het Loops-blok over de lokale geschiedenis van één machine rekent en daar nog geen volle week aan runs op staat. Zodra dat getal er is, komt het hier te staan.