Tokenmaxxing

Wat is tokenmaxxing?

Tokenmaxxing wil zeggen dat je het aantal AI-tokens dat iemand verbruikt als maat neemt voor hoe productief die persoon is. Veel tokens, goede medewerker. Weinig tokens, iemand die nog niet mee is.

Het woord leent het achtervoegsel "-maxxing" uit online jargon, waar het betekent dat je aan een enkele knop draait tot het niet verder kan en de rest zichzelf maar moet oplossen. Toegepast op AI heeft het twee betekenissen die door elkaar gebruikt worden, en daar zit de meeste verwarring. De ene is opschepperij: ik heb meer van de tool gebruikt dan jij. De andere leunt tegen engineering aan: haal zoveel mogelijk werk uit elke token die je betaalt. Hetzelfde woord, tegenovergesteld gedrag.

Niemand kan aanwijzen wie het als eerste gezegd heeft. Het circuleerde in de eerste maanden van 2026 in ontwikkelaars- en AI-kringen, half als grap en half als statusclaim, en stond tegen april van dat jaar in de technologiepers. Zie je het toegeschreven aan een bepaalde oprichter of investeerder, beschouw dat dan als een gok. Wat wel gedocumenteerd is, is hoe snel het van een grap naar een managementpraktijk verschoof.

De ranglijst bij Meta, en de discussie die erop volgde

In april 2026 bouwde een medewerker bij Meta een intern dashboard met de naam Claudeonomics, dat collega's rangschikte op tokenverbruik en labels als Token Legend en Cache Wizard uitdeelde aan de top 250. Fortune berichtte dat het personeel over dertig dagen meer dan 60 biljoen tokens verbruikt had, dus 60.000 miljard, en dat noch Mark Zuckerberg noch Andrew Bosworth in die top 250 stond. Business Insider berichtte dat het dashboard twee dagen na het uitlekken van de cijfers offline ging. Meta zei dat de medewerker het uit eigen beweging weggehaald had.

Die discussie is nuttiger gebleken dan het dashboard zelf. Sonya Huang, partner bij Sequoia Capital, zei in de Wall Street Journal dat we allemaal aan tokenmaxxing zouden moeten doen. Cristina Cordova, chief operating officer bij Linear, verwoordde de andere kant in een zin: ontwikkelaars rangschikken op tokenverbruik is hetzelfde als een marketingteam rangschikken op wie het meeste geld uitgaf, en veel verbruiken is niet hetzelfde als veel opleveren. Jon Chu van Khosla Ventures zei dat mensen bots aan het bouwen waren die in een loop draaien om zo snel mogelijk tokens op te branden, precies door dat beleid.

Gergely Orosz, die The Pragmatic Engineer schrijft, maakte de vergelijking die aankomt bij iedereen die al een tijd in software zit. Dit zijn regels code met een nieuwe eenheid. Regels code tellen is als productiviteitsmaat afgeschaft omdat het volume beloonde, en volume is niet wat je koopt.

Waarom een manager naar het tokenaantal grijpt

Begin bij de eerlijke reden, want dit is geen domheid. Het tokenaantal is het enige cijfer dat je gebruiksdashboard je gratis geeft. Er is geen definitieworkshop voor nodig, geen meetproject en geen discussie met het team over wat meetelt. Het komt dagelijks binnen, het staat per persoon, en het stijgt zodra mensen de tool gebruiken. Adoptie is meestal net wat de manager moest opleveren, dus een cijfer dat adoptie volgt voelt als een cijfer dat het doel volgt.

Lees wat die dashboards effectief beloven en het beeld wordt smaller. De Claude Code-analytics van Anthropic voor Teams en Enterprise bevat een ranglijst van topgebruikers op verbruik, naast aanvaarde regels code, het percentage aanvaarde suggesties, dagelijkse actieve gebruikers en sessies. De leverancier levert de ranglijst zelf mee. Anthropic is er ook duidelijk over wat een van die cijfers weglaat: aanvaarde regels code telt afgewezen suggesties niet mee en houdt geen rekening met wat er nadien weer geschrapt wordt. Een regel die om elf uur aanvaard wordt en om half twaalf verdwijnt, blijft meetellen.

Het gebruiksrapport voor Copilot Chat in het Microsoft 365-beheercentrum zit hetzelfde in elkaar. Een actieve gebruiker is daar een gebruiker die in de periode minstens één prompt heeft ingediend. De tabel per persoon geeft je ingediende prompts, actieve dagen en de datum van de laatste activiteit. Elk van die cijfers is een precieze definitie van precies wat er staat, en geen enkel daarvan gaat over werk dat afraakt.

Je gebruiksdashboard vertelt je dat mensen de tool geopend hebben. Het zegt niets over wat daaruit gekomen is.

Waar een hoog tokenaantal echt uit bestaat

Een tokenfactuur is geen verslag van nadenken. Het is een verslag van tekst die verplaatst is. Vier dingen verplaatsen het grootste deel, en geen enkele daarvan is vakmanschap.

• Context die bij elke stap opnieuw meegaat. Een agent die een taak afwerkt stuurt bij elke beurt het hele gesprek opnieuw mee. Een context van 100.000 tokens wordt aangerekend bij stap 2 en opnieuw bij stap 40. De lengte van de run bepaalt de factuur meer dan de moeilijkheid van het probleem.

• Nieuwe pogingen. Een test die blijft falen en die de agent dertig keer opnieuw probeert, wordt dertig keer aangerekend. Er gaat niets in fout, dus er stopt niets.

• Slechte afbakening. Iemand plakt een hele repository in een prompt zodat het model alles heeft. Die ene beslissing vermenigvuldigt elke stap die erna komt.

• Een loop die niemand opgemerkt heeft. De agent vindt een document niet, dus zoekt hij, leest, herformuleert en leest opnieuw. Elke oproep kost een fractie van een cent en de run is het ongeluk.

En dan is er het detail dat de ranglijst helemaal onderuit haalt. Met prompt caching betaal je een tiende van de gewone inputprijs voor inhoud die het model al gezien heeft: Anthropic rekent een cache hit bij de meeste van zijn modellen aan tegen 0,1 keer de basisprijs voor input. Tokens uit de cache blijven tokens. Anthropic telt in zijn verbruiksrapportage niet-gecachete input, gecachete input, cacheopbouw en output als aparte cijfers, en ze tellen allemaal mee in je verbruik. Caching aanzetten haalt dus ongeveer negentig procent van je factuur en verandert je plaats in de ranglijst niet. Bij identiek werk staat de collega die caching nooit ingesteld heeft boven de collega die dat wel deed.

Wie bovenaan een tokenranglijst staat, is dus even goed de persoon met de slechtste werkwijze als de beste, en het cijfer kan je niet zeggen naar welke van de twee je zit te kijken.

Twee collega's, tien keer zoveel tokens

Een Vlaams softwarebedrijf van veertien mensen geeft iedereen een AI-assistent voor programmeerwerk op Claude Sonnet 5, in september 2026 geprijsd op 2 dollar per miljoen inputtokens en 10 per miljoen outputtokens. Twee ontwikkelaars, één maand, twintig werkdagen.

Bram staat bovenaan de gebruikslijst. Hij draait ongeveer 2.000 agentstappen die maand. Hij start elke sessie met de repository erin te plakken zodat het model het volledige plaatje heeft, wat bij elke stap ruwweg 190.000 tokens context meestuurt. Dat is 380 miljoen inputtokens, zo'n 760 dollar. Zijn outputtokens komen op ongeveer 1,2 miljoen, zo'n 12 dollar. Hij leverde 11 wijzigingen op. Drie daarvan kwamen binnen de vier weken terug als bug gemeld door een klant, en wie ze nakeek was er telkens een veertigtal minuten mee bezig, omdat de wijzigingen groot waren en bestanden raakten die niet geraakt moesten worden.

Lies staat bijna onderaan die lijst. Ook zij draait ongeveer 2.000 stappen. Ze schrijft eerst drie lijnen specificatie, wijst de agent de drie bestanden aan die ertoe doen, en zet hem stil zodra hij afdwaalt. Haar context blijft rond 19.000 tokens per stap, dus 38 miljoen inputtokens, zo'n 76 dollar, plus diezelfde 12 dollar output. Zij leverde er 13 op. Eén kwam er terug. Nakijken kostte telkens een kwartier.

Op het dashboard is Bram de power user en lijkt Lies afwezig. Over die maand kostte Bram 772 dollar aan tokens en zo'n 7 uur nakijkwerk van iemand anders, voor 11 wijzigingen met 3 fouten. Lies kostte 88 dollar en zo'n 3 uur nakijkwerk, voor 13 wijzigingen met 1 fout. Het tokenaantal heeft die twee op precies één ding juist gerangschikt, namelijk hoeveel tekst ze verstuurd hebben.

Kijk ook waar het geld naartoe ging. Bijna niets ervan is wat het model geschreven heeft: 12 dollar van Brams 772, en 12 van de 88 van Lies. Al de rest is context die naar binnen ging. Een dashboard dat tokens rapporteert, rapporteert vooral hoeveel geschiedenis er opnieuw meegestuurd werd, en dat is een eigenschap van de werkwijze, niet van hoe hard iemand gewerkt heeft.

Wat er gebeurt als het cijfer een doel wordt

Zodra mensen weten dat ze erop gerangschikt worden, beschrijft het cijfer niets meer. Het artikel over automatiseringsgraad legt uit waarom elke maatstaf in elkaar zakt zodra mensen erop afgerekend worden, dus beschouw dat als gekend. De vorm die het aanneemt bij AI-gebruik is apart genoeg om wel te benoemen.

Mensen gaan genereren. Als je moet aantonen dat je de tool gebruikt, is de goedkoopste manier om daaraan te voldoen het model meer werk sturen dan de opdracht vraagt: langere prompts, bredere context, een tweede en derde versie waar niemand om gevraagd heeft, een samenvatting van de samenvatting. De bots in een loop die Jon Chu beschreef zijn de geautomatiseerde versie van datzelfde instinct, en ze zijn sneller gebouwd dan uitgelegd.

Wat eruit komt is het weinig waardevolle, geloofwaardig ogende werk dat het artikel over AI slop en workslop beschrijft, en de kost daarvan komt niet terecht bij wie het gegenereerd heeft. Ze komt terecht bij wie het moet lezen. Een collega die veertig minuten besteedt aan het nakijken van een wijziging die twee minuten kostte om te maken, heeft werk toegeschoven gekregen door een meting, en die verschuiving is op geen enkel betrokken dashboard te zien.

Er komt later nog een kost bij. Gergely Orosz waarschuwde dat AI-gebruikscijfers uiteindelijk kunnen meewegen in beslissingen over wie blijft, en zodra dat idee in huis is, sturen mensen op het cijfer, wat ze er zelf ook van denken. Op dat moment betaal je de tokens en krijg je er indekgedrag bovenop, precies de grond die het artikel over AI-moeheid en cognitieve schuld beschrijft.

De regel geldt evengoed in de andere richting. Een team dat het tokenverbruik naar beneden moet krijgen, begint werk manueel te doen zonder het te registreren. Dat verlaagt het cijfer en geen enkele kost.

Wat ernaast moet staan

Meet het werk, niet het verbruik. Afgewerkte dossiers per persoon per week, doorlooptijd van binnenkomst tot klaar, het aandeel correcties en terugdraaiingen, en de kost per dossier met de belaste personeelstijd erin. Dat zijn de cijfers die je al had voor AI er was, ze zijn vergelijkbaar met een kwartaal geleden, en ze bewegen alleen als er echt iets gebeurt. Zet de tokenkost op diezelfde pagina als één lijn: kost. Ze hoort in de kost per dossier, naast de softwarelicenties en de uren.

Tokenverbruik tegenover afgewerkt werk

Zet de twee naast elkaar op één dimensie: wat elk cijfer een manager vertelt over de persoon.

Tokenverbruik zegt hoeveel tekst die persoon naar een model gestuurd heeft. Het stijgt met nieuwe pogingen, met lange context die bij elke stap opnieuw meegaat, met een prompt waar een hele repository in zat, en met caching die nooit ingesteld raakte. Het daalt als iemand een taak goed afbakent. Het heeft geen eenheid die iemand buiten het team herkent, en je kan het niet vergelijken met een collega die ander werk doet.

Afgewerkt werk zegt wat de zaak eraan gehad heeft. Afgesloten tickets, doorgevoerde wijzigingen, gematchte facturen, gewonnen dagen. Het staat uitgedrukt in iets dat een klant herkent, het is dezelfde maat voor wie de hele dag op AI leunt en voor wie er nauwelijks aankomt, en het beloont volume niet.

Het ongemakkelijke eraan is dat het eerste vanmiddag al beschikbaar is en het tweede een maand definitiewerk vraagt. Dat is het enige echte voordeel dat tokens hebben.

Wanneer het tokenaantal wel een blik waard is

Niet per persoon. Per run. Tokenverbruik is een goede afwijkingsdetector en een slechte prestatiemaat, en het verschil zit in of je naar het niveau kijkt of naar de verandering.

Een nachtelijke afpuntjob die een maand lang elke nacht 4 dollar kostte en vannacht 41 dollar kostte, zegt je iets concreets: een loop, een reeks mislukte pogingen, een document dat niet gevonden raakt, of een input die tien keer groter is dan gewoonlijk. Dat is een alarm waard en twintig minuten van iemands ochtend. Hetzelfde geldt voor één sessie die drie keer langer draait dan elke sessie ervoor. Log per run het kenmerk, de gebruiker, het model, de tokentotalen en de eindkost, zodat het alarm kan zeggen welke job het was. Waar je dan uitkomt is een uitgavencontrole en geen scorebord, en het artikel over de uitgavenlimiet voor agents legt uit hoe je er een instelt.

Als je AI-gebruiksrapport het enige bewijs is dat je hebt dat de investering werkt, dan heb je nog geen bewijs. Ga eens aan wie het resultaat nakijkt vragen of zijn week lichter geworden is.