Tokenmaxxing: wat er gebeurt als je het verkeerde meet

In juni schreef ik deze post op basis van krantenkoppen, en een aantal daarvan had ik verkeerd. Het argument bleef overeind. Vier maanden later zeggen de betrokken bedrijven het zelf, en ik heb het op kleine schaal gemeten. Dit is de gecorrigeerde post.

Wat er gebeurde, nu met bronnen ​

Het idee van tokens als productiviteitsmaat kwam van bovenaf. In de All-In-podcast tijdens GTC in maart zei Jensen Huang over zijn engineers: "If that $500,000 engineer did not consume at least $250,000 worth of tokens, I'm going to be deeply alarmed." De uitspraak over managers die AI afremmen kwam eerder, uit een all-hands bij Nvidia in november 2025: "Are you insane?" In mijn versie van juni liepen die twee door elkaar.

Dan de scoreborden. "Claudeonomics" was een dashboard dat een medewerker van Meta bouwde om collega's op tokenverbruik te rangschikken, en het ging offline nadat er in april over werd bericht. Ik had het aan Amazon toegeschreven. Amazon had een eigen scorebord, KiroRank, waarop medewerkers volgens de Financial Times de tool voor triviale taken gebruikten om hun score op te krikken. Amazon haalde het eind mei offline, vanwege de rekenkosten.

Daarna kwamen de rekeningen. Uber had zijn budget voor AI-codingtools van 2026 in vier maanden op. COO Andrew Macdonald zei in mei in de podcast Rapid Response dat het verband met resultaten ontbrak: "That link is not there yet." Ik had die zin aan de CTO gegeven, in woorden die hij nooit gebruikte. Een consultant vertelde Axios over een klant die in één maand $500 miljoen aan Claude uitgaf, zonder limieten. Dat bericht berust op één anonieme bron en niemand heeft het sindsdien bevestigd.

Wat er sinds juni veranderde ​

De bedrijven die het gebruik aanjoegen, remmen nu af, en ze zeggen waarom.

• Microsoft. Begin augustus schreef EVP Jay Parikh in een e-mail, gemeld door 404 Media en The Register: "Tokenmaxxing is not what we are optimizing for." Hij somde op waarvoor betaald werd: "idle agents left running, questions asked of the model that the engineer already knew the answer to, work split into more turns than it needs." Divisies krijgen nu tokendoelen. In juni schreef ik dat Microsoft de meeste Claude Code-licenties had opgezegd. Het ging om één divisie die overstapte op Copilot CLI.
• Uber. Op 7 augustus zei CTO Praveen Neppalli Naga: "We're coming to the end of the so-called tokenmaxxing era."
• De branche. In het AI Impact Report 2026 van LeadDev noemt 19% van de respondenten tokenmaxxing effectief, en zegt 57% dat het geen echte waarde laat zien.

Dat betekent niet dat de tools niets opleveren. Een veldonderzoek bij Microsoft uit juli vond dat engineers die Claude Code of Copilot CLI gingen gebruiken zo'n 24% meer pull requests mergeden, met de kanttekening van de onderzoekers dat "a merged PR is not the same as the value it delivers". Een tweede onderzoek, onder 802 developers bij een bedrijf dat zijn output wilde verdubbelen, zag de doorvoer uitkomen op 2,09 keer het oude niveau, terwijl de belasting per reviewer ongeveer verdubbelde. Die output is echt, en het aantal tokens zegt er weinig over.

Dezelfde fix op vijf effort-niveaus ​

Scoreborden meten mensen. Ik wilde hetzelfde zien binnen één taak: krijg je een beter resultaat als je meer tokens aan een probleem besteedt?

In Claude Code stel je per sessie het effort-niveau in, van low tot max. Dat bepaalt hoeveel het model nadenkt en hoe grondig het werkt. Ik gaf Opus 5 op elk niveau dezelfde kleine bugfix, drie runs per niveau, op Claude Code 2.1.273.

De taak is een LRU-cache met time-to-live van 45 regels JavaScript, die op meerdere plekken afwijkt van zijn eigen README. De issue beschrijft er maar één: een entry die net gelezen is, wordt toch uit de cache gezet. De prompt was elke keer hetzelfde:

Fix the issue described in ISSUE.md. The intended behaviour of the cache is
specified in README.md. You can run the tests with npm test.

claude -p "$PROMPT" --model claude-opus-5 --effort $LEVEL \
  --tools Read Edit Write Bash Glob Grep --permission-mode acceptEdits \
  --setting-sources "" --strict-mcp-config --output-format json

Daarna beoordeelde ik elk resultaat met 13 tests die het model nooit te zien kreeg en die samen de hele README afdekken. De oorspronkelijke code haalt er 5. Een correcte implementatie haalt ze alle 13.

Veertien van de vijftien runs losten alles op wat de verborgen tests controleren. max produceerde 22 keer zoveel output tokens als low, kostte 13 keer zoveel en duurde 20 keer zo lang, voor precies dezelfde geslaagde tests. Op een token-scorebord winnen de max-runs met afstand.

Die ene lagere score is het lezen waard. De xhigh-run in kwestie repareerde de eviction-bugs die bij de issue hoorden, en noemde de resterende problemen met verlopen entries, size en delete, met het aanbod ook die op te lossen. Bij een prompt die "fix the issue" zegt, is dat een verdedigbare keuze, en het laat zien hoe weinig een testscore over oordeelsvermogen zegt.

De beperking van deze test is zijn omvang. low zit al aan het plafond, dus hij laat alleen zien dat de extra tokens hier niets opleverden. Of ze bij groter en minder scherp omschreven werk wel iets opleveren, beantwoordt deze test niet. Daarom loont het om het effort-niveau per taak te kiezen in plaats van standaard het hoogste te nemen. Een groter onderzoek wijst dezelfde kant op: in een analyse uit april van acht frontier-modellen op SWE-bench Verified liep het tokengebruik van runs op dezelfde taak tot een factor 30 uiteen, en "higher token usage does not translate into higher accuracy; instead, accuracy often peaks at intermediate cost and saturates at higher costs."

Goodhart, goed geciteerd ​

De zin die iedereen aanhaalt, "when a measure becomes a target, it ceases to be a good measure", is de samenvatting die Marilyn Strathern in 1997 gaf van wat Charles Goodhart in 1975 bedoelde. In juni schreef ik hem aan Goodhart toe. Het idee klopt hoe dan ook, en tokens zijn er een zuiver voorbeeld van: het getal stijgt of er nu iets nuttigs gebeurde of niet, en de makkelijkste manier om het op te drijven is minder nuttig werk duurder doen.

Je kent het patroon van velocity points en code coverage. Tokens voegen er iets aan toe dat die nooit hadden: elk punt op het scorebord komt binnen als factuur, zeker nu aanbieders de teller hebben aangezet.

Wat je wel telt ​

Waar de memo van Microsoft over klaagt en wat de twee veldonderzoeken maten, wijst op een handvol getallen om in de gaten te houden. Geen daarvan is een tokentelling.

• Kosten per gemergede wijziging. Tokenuitgaven gedeeld door wat echt op main terechtkwam. Dat getal stijgt als agents stilstaan of rondjes draaien, precies de verspilling die Parikh opsomde.
• Belasting per reviewer. In het onderzoek naar de verdubbelingsopdracht verdubbelde de belasting per reviewer ongeveer mee met de doorvoer. Stijgt dit sneller dan het gemergede werk, dan zit de bottleneck bij mensen, en maken meer tokens het erger.
• Revert- en herwerkpercentage. Hoeveel van wat gemerged werd, binnen een paar weken is teruggedraaid of herschreven. Doorvoer die terugkomt, telt niet.
• Tijd tot een gemergede fix. Van issue tot merge, en dat is wat het bedrijf eigenlijk wilde kopen.

Het zijn ook de enige cijfers waar je een planning op kunt bouwen. Zodra je kijkt wat er werkelijk de deur uit ging, houdt de zelfgerapporteerde snelheidswinst geen stand. En als geen van deze getallen beweegt, lag het probleem waarschijnlijk altijd al in het proces.

De bedrijven met token-scoreborden maten wat makkelijk te tellen was, en wat makkelijk te tellen was, bleek de kostenpost. Mijn test zegt hetzelfde op de schaal van een paar dollar: de duurste run was de run die het hardst zijn best deed, en hij loste niets op wat de goedkoopste run niet ook oploste.