Observaties over het tokenverbruik van AI-agents

Een nieuw paper van onderzoekers van Stanford, Michigan, DeepMind, All Hands, Microsoft AI en MIT is de meest gedetailleerde open empirische studie die ik ken over hoe AI-agents op schaal echt tokens uitgeven¹. De auteurs draaien acht frontiermodellen op 500 SWE-bench Verified-taken, elk vier keer, en leggen de volledige trajectorietelemetrie vast, uitgesplitst naar tokentype, fase en actie. Ze publiceren de dataset bij het paper. Voor zover ik weet is dat het meest gedetailleerde openbare corpus van agentische trajecten dat nu bestaat.

Het paper is degelijk, voorzichtig over wat het claimt en zet harde cijfers op vragen die tot nu toe alleen met anekdotes beantwoord werden. Ik raad aan het helemaal te lezen.

Hieronder loop ik door vier van de observaties uit het paper, afgewisseld met wat wij bij Flowstate zien van precies dezelfde patronen in klantomgevingen. Wij zitten in het verzoekpad tussen de gebruiker en de AI-aanbieder. Daardoor zien we dezelfde trajecten die het paper analyseert, maar dan in productie en over een veel bredere set AI-tools dan SWE-bench dekt.

De twee sets observaties liggen opvallend dicht bij elkaar. De onderzoekers maten het op een benchmark, wij zien het op klantapparaten. Dat die twee overeenkomen, maakt dit paper zo nuttig voor iedereen die deze uitgaven daadwerkelijk wil beheersen.

Inputtokens domineren agentische uitgaven

De eerste bevinding van het paper is dat agentisch coderen ongeveer 1.000 keer meer tokens verbruikt dan vergelijkbare codechat- of codeerredeneertaken, met een input-outputverhouding van grofweg 153:1 (tegenover 1,33 voor chat en 0,16 voor redeneren)².

De reden is structureel. Agentische workflows stapelen context op over rondes heen, en dezelfde inhoud gaat bij elke beurt opnieuw het model in. Token caching helpt aan de randen, maar de pure hoeveelheid opgebouwde context bepaalt de kosten.

Precies dit patroon zien we ook bij niet-agentisch AI-gebruik. Chatgebruik van Claude, ChatGPT en vergelijkbare tools heeft dezelfde vorm, omdat gebruikers gesprekken over meerdere dagen voortzetten in plaats van verse sessies te starten met expliciete context. Een klant beschreef het zo:

“We think they’re creating PowerPoints, and then they’re like, ‘change this word on slide three’, and then they’re just continuing to generate these really large documents.”

Dat is de bevinding van het paper in menselijke vorm. Een chatsessie die een verse prompt had moeten zijn, wordt een draad die bij elke beurt opnieuw betaalt voor zijn hele geschiedenis. De gebruiker denkt dat hij één kleine aanpassing doet. Het model moet het hele document opnieuw verwerken. De aanbieder rekent daarvoor af.

De les is dat een groot deel van de beheersbare AI-kosten vóór het model ligt. Betere prompts. Verse sessies. Expliciete context één keer aanleveren, in plaats van die over een middag stukje bij beetje op te bouwen. Het gedrag van de agent volgt grotendeels uit hoe die is ingericht.

Modelkeuze geeft kostenverschillen van een orde van grootte

Op de 230 SWE-bench-taken die elk geteste model succesvol oploste, gebruikten Kimi-K2 en Claude Sonnet 4.5 gemiddeld 1,5 miljoen tokens meer dan GPT-5³. Dezelfde problemen, dezelfde juiste antwoorden, hopeloos verschillende tokenhonger.

Het paper sluit de voor de hand liggende verklaring zorgvuldig uit: het kostenverschil blijft bestaan op zowel de subset die iedereen oploste als de subset die iedereen niet oploste. De duurdere modellen pakten geen moeilijkere problemen aan. Ze gaven op dezelfde problemen simpelweg meer tokens uit.

Dit past bij gedrag dat we steeds zien. Gebruikers pakken het model dat in de UI het meest opvalt, en “het meest opvallend” betekent meestal het duurst. Opus waar Sonnet de klus had geklaard. Aanbieders hebben geen commerciële prikkel om gebruikers naar goedkopere modellen te sturen. Uit een ander klantgesprek:

“We definitely know that people are using just all Opus. The people that are using up their tokens, they’ll continue to do that unless there’s a way to control it. We did not know there was a way to control that in Claude. I know there isn’t.”

Er is wel een manier om dit te sturen, maar die zit niet in het product van de aanbieder. De logische plek is de laag die de taakcategorie kan zien en per verzoek kan routeren: standaardwerk naar het slankere model, langdurige planning naar het zwaardere. De bevinding uit Stanford dat tokenefficiëntie een eigenschap van het model is en niet van de taak, maakt routeren juist haalbaar. Als zwaardere modellen alleen meer tokens verbruikten op moeilijkere problemen, zou routeren nutteloos zijn. Dat doen ze niet, dus is het dat niet.

Tokengebruik varieert sterk en is lastig te voorspellen

De derde observatie van het paper is dat vier runs van hetzelfde model op dezelfde taak tot 30x verschil in totale tokenkosten kunnen geven⁴. De duurste run op een bepaald probleem kost gemiddeld ongeveer twee keer zoveel als de goedkoopste. Naarmate de kosten stijgen, daalt de voorspelbaarheid.

Scherper nog: de auteurs testen of agents hun eigen tokengebruik kunnen voorspellen voordat ze een taak uitvoeren. De correlaties bleven hoogstens 0,39. Alle acht modellen onderschatten systematisch⁵. Zelfs de agent weet niet wat een taak gaat kosten.

Aan de klantkant zien we leidinggevenden die de uitgaven proberen te sturen met de enige data die ze hebben. Meestal een chatcount uit het beheerdashboard van een aanbieder:

“What are these five people doing? They’re always saying they don’t have enough tokens.”

Een chatcount beantwoordt dit niet. Een tokencount zegt hoeveel er is uitgegeven, maar niet waarom. Dat “waarom” is structureel onzichtbaar op de factuur. Je ziet het alleen in de verzoeklaag, waar het eigenlijke werk te zien is. Geen enkele voorspelling vooraf dicht dat gat, want het werk zelf is stochastisch.

Hogere kosten leveren geen hogere nauwkeurigheid op

Het paper deelt de runs in kostenkwartielen in en ziet dat de nauwkeurigheid piekt in het op een na goedkoopste kwartiel en daarna vlak blijft. De duurste runs leveren geen betere uitkomsten dan matig geprijsde⁶.

De auteurs herleiden dit tot een specifiek gedragspatroon: in het duurste kwartiel zijn herhaalde bestandswijzigingen ongeveer 4x zo frequent als in het goedkoopste kwartiel, en herhaalde bestandsweergaven 2x zo frequent⁷. De dure runs doen niet meer werk. Ze doen hetzelfde werk opnieuw, op dezelfde bestanden.

Het paper noemt dit beleefd “unproductive exploration rather than deeper reasoning.” We zien dezelfde vorm bij AI-gebruik buiten het coderen. Hetzelfde artefact telkens opnieuw genereren met kleine aanpassingen. Langlopende sessies waar de gebruiker uren geleden al afgehaakt is. Identieke prompts die opnieuw worden gestuurd na een typfout. Geen van die dingen is een fout van de agent. Het zijn patronen van de gebruiker die de agent erft.

Het meetgat

Geen van bovenstaande patronen is op schaal aan te pakken zonder meting in de verzoeklaag. Dashboards van aanbieders aggregeren per tool en tenant. AI-gateways (een proxy tussen jou en je AI-aanbieder) dekken serverside productieroutering. Tools voor engineeringeffectiviteit dekken smalle codeerassistenten en stoppen daar.

We bouwden Flowstate omdat de meetlaag die je nodig hebt om op deze patronen te handelen nergens in de stack bestond.

Flowstate ziet elke AI-aanroep van een gebruiker, of dat nu ChatGPT in de browser is, Claude Code in de terminal, Midjourney voor beeld of Suno voor audio, en koppelt elke aanroep terug aan een gebruiker, project, model en kostenklasse⁸. Klanten houden hun eigen contracten en hun eigen API-sleutels bij elke aanbieder die ze gebruiken. Wij verkopen geen toegang tot AI en we beperken niet welke tools mensen mogen pakken.

Die architectuurpositie heeft gevolgen die verder gaan dan kostenmeting. Dezelfde instrumentatie die tokenverspilling zichtbaar maakt, toont ook patronen die voor beveiliging tellen. Prompts met klant-PII die naar een consumenten-AI-tool gaan. Broncode die in ChatGPT wordt geplakt. Medewerkers die zijprojecten draaien op het bedrijfsabonnement. We zien die in het veld alleen omdat de verzoeklaag de enige plek is waar ze zichtbaar zijn.

Het Stanford-paper maakt een heldere economische zaak vanuit een benchmark. Onze observaties maken precies dezelfde zaak vanuit echte bedrijfsomgevingen. De patronen achter AI-kosten zijn groot, meetbaar en consistent. Je hebt alleen het leidingwerk nodig om ze te zien.

Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., and Pei, J. (2026). How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks. arXiv:2604.22750v2. De auteurs noemen gelijktijdig werk over tokenverdeling in multi-agentsystemen (Salim et al. 2026, Wang et al. 2025) en prijsdynamiek in redeneermodellen (Chen et al. 2026), maar de combinatie van schaal, detail en open datapublicatie maakt dit paper het nuttigste dat ik ken om te begrijpen hoe agentische uitgaven er echt uitzien. De auteurs publiceren ook een projectwebsite met de trajectoriedataset, een analysecoderepo om de figuren na te maken, en een leuk interactief spel, Can You Guess the Token Cost?, dat de kernbevinding van het paper in ongeveer dertig seconden duidelijk maakt. ↩
Bai et al., Figuur 1. Agentisch coderen gemiddeld 4,17M tokens per taak en $1,86 aan kosten, tegenover 3,39k tokens voor codechattaken en 1,19k tokens voor code-redeneren in één beurt. Het cijfer van 1.000x is de verhouding tegenover redeneren. Tegenover chat is het ongeveer 1.200x. ↩
Bai et al., Figuur 6 en Sectie 4. Sectie 4 gaat specifiek in op het bezwaar dat “moeilijkere taken nu eenmaal meer kosten”, door te laten zien dat het verschil blijft bestaan op de subset die iedereen oploste (n=230 taken opgelost door elk geteste model). De auteurs beschrijven het verschil als “model-specific behaviour rather than intrinsic task difficulty.” ↩
Bai et al., Figuur 2a en 2b. Tot 30x variatie tussen instanties. Bij dezelfde taak over vier runs kost de duurste run gemiddeld ongeveer 2x zoveel als de goedkoopste. ↩
Bai et al., Figuur 10 en Figuur 11. De beste correlatie over alle acht modellen is 0,39 (Claude Sonnet 4.5, outputtokens). Voorspelling van inputtokens is overal slechter dan die van outputtokens. Elk model onderschat systematisch. Figuur 11 laat zien dat voorspellingen over de hele linie ver onder de diagonaal clusteren. ↩
Bai et al., Figuur 3b. De nauwkeurigheid stijgt significant van het goedkoopste naar het op een na goedkoopste kwartiel en vlakt daarna af. Het derde en vierde kwartiel zijn statistisch niet te onderscheiden van het tweede. ↩
Bai et al., Figuur 4 en Appendix A. Gemengde-effectenregressiecoëfficiënten van grofweg 4x voor herhaalde wijzigingen en 2x voor herhaalde weergaven in het duurste kwartiel, beide significant bij p < 0,001 tegenover de groep met minimale kosten, gecorrigeerd voor modelidentiteit. De outputtokenanalyse in de appendix laat hetzelfde patroon zien. ↩
Flowstate. Ik ben medeoprichter, dus de voor de hand liggende melding van belangenverstrengeling geldt. ↩