Vad är tokenmaxxing? AI-måttet som kollapsade

På 30 dagar skickade Meta-anställda cirka 60 biljoner AI-tokens genom en intern topplista som rankade dem efter förbrukning; en kostnad som troligen översteg 100 miljoner dollar för att producera arbete som till stor del var rent performativt. Nittio dagar senare var topplistan borta, och företaget rationerade AI strikt.

Denna utveckling kallas tokenmaxxing: det är när maximering av AI-tokenanvändningen lyfts fram som ett prestationsmått och en indikator på produktivitet. Företagen har sedan dess blivit klokare, och vissa har överkorrigerat i ett fenomen som fått smeknamnet ”tokenminning”: att använda så få AI-tokens som möjligt för att minska datorkostnaderna. Båda tillvägagångssätten misslyckas eftersom de behandlar antalet tokens som en tillförlitlig indikator på AI-driven tillväxt.

I den här artikeln går vi igenom vad tokenmaxxing faktiskt kostar, hur ingenjörer utnyttjade systemet och hur mätmetoden är utformad för att klara av personer som är duktiga på att manipulera siffror.

Vad är tokenmaxxing?

Tokenmaxxing är en metod som går ut på att maximera förbrukningen av AI-token och betrakta en högre användning som ett tecken på ökad produktivitet eller ökad användning av AI. Token är de enheter som en AI-modell bearbetar som indata och producerar som utdata.

Tokenanvändningen blev ett attraktivt prestationsmått eftersom den är synlig, mätbar och redan spåras av många AI-plattformar. Det gör den lättare att redovisa än resultat som tidsbesparingar, förbättrade beslut eller genererade intäkter. Men tokens mäter beräkningsaktivitet, inte nyttigt arbete. Repetitiva frågor, misslyckade agentloopar och meningslösa utdata driver alla upp siffran utan att producera någonting.

AI-agenter förvärrar situationen. En agent tolkar sammanhanget, anropar verktyg, granskar sitt eget arbete och delegerar uppgifter till andra agenter. Varje steg förbrukar tokens. Även om ökad aktivitet kan innebära mer produktivt arbete, kan det också leda till ineffektiva arbetsflöden och stigande kostnader.

Enkelt uttryckt är den centrala bristen med tokenmaxxing att teamen maximerar det synliga antalet samtidigt som produktivitet, kvalitet och avkastning på investeringen förblir oförändrade.

Varför blev tokenmaxxing populärt?

Tokenmaxxing blev populärt eftersom ledningen behövde ett tal för att bevisa att AI verkligen infördes inom företagen. Och tokenanvändningen var det enda måttet som visades i faktureringskonsolen.

Nvidias VD Jensen Huang satte tonen redan i början av 2026 i podden All-In Podcast med ett tankeexperiment om en högavlönad ingenjörs tokenräkning.

”Om den där ingenjören som tjänar 500 000 dollar inte förbrukar tokens till ett värde av minst 250 000 dollar kommer jag att bli djupt oroad”, sa han. Och om svaret blev 5 000 dollar? Då skulle han bli rasande.

AI-användningen hade blivit en tydlig indikator på vem som hängde med. Detta skedde vid en tidpunkt då frågor om vilka roller AI skulle ta över kom upp vid varje planeringsmöte. Ingenjörer som använde tokens såg ut att anpassa sig till det nya paradigmet, medan de som inte gjorde det riskerade att framstå som ett problem.

Här är det ironiska: den första token-rankningen var aldrig tänkt att vara en tävling. Shopify skapade den för att förstå varför deras främsta kunder spenderade så mycket, inte för att rangordna dem mot varandra. Vice VD och teknikchef Farhan Thawar beskrev senare hur verktyget utvecklades.

Företaget döpte om det till en ”användningsinstrumentpanel”, lade till säkerhetsbrytare och utgiftsvarningar och använde data för att upptäcka okontrollerade agenter och infrastrukturfel. Farhan skrev:

Tokenmaxxing är ett hett ämne. Mer betyder inte bättre. Vi skapade den första ranklistan för AI-tokens. Sedan utvecklade vi vårt tänkande. Det blev en användningsöversikt. Samma data, men med en annan inramning. Vi lade till säkerhetsbrytare och utgiftsspikar. Fångade upp okontrollerade agenter. Hittade buggar i vår egen infrastruktur. Den verkliga signalen: inte vem som spenderade mest, utan de vars tokens genererade störst effekt. Det är de ingenjörerna jag vill prata med.

De flesta företag som kopierade Shopifys topplista använde den för att rangordna anställda istället för att granska AI-utgifterna. Tabellen nedan visar hur det gick för vart och ett av dem.

Mönstret i denna tabell är konsekvent. Organisationer som använde token-data för att undersöka höga utgifter behöll en fungerande signal. Andra som använde den för att rangordna personer förlorade den signalen inom ett kvartal.

Hur lyckades ingenjörerna blåsa upp sin tokenanvändning?

Ingenjörer blåste upp sin tokenanvändning genom att generera kostsam AI-aktivitet som de aldrig hade tänkt att lansera. The Pragmatic Engineer rapporterade om detta beteende hos Meta, Microsoft och Salesforce och fann fyra vanliga taktiker. Ingen av dem innebar illvilja. Människor såg helt enkelt ett synligt siffra, oroade sig för uppsägningar och antog att omfattande AI-användning skulle skydda dem:

Många ingenjörer kollade vad deras kollegor förbrukade. Därefter förbrukade de precis tillräckligt för att ligga något över genomsnittet. Mer än att ligga i topp ville de undvika att bli flaggade för att inte använda AI tillräckligt.

På Amazon tilldelade medarbetare triviala och påhittade uppgifter till AI-agenter för att höja sina Kirorank-poäng. Detta ökade molnkostnaderna utan att ge något affärsmässigt resultat. När Amazon tog bort topplistan sa senior vice president Dave Treadwell till personalen att den hade skapats med goda avsikter. Han bad sedan rakt på sak: ”Använd inte AI bara för att använda AI.”

Som en del av förändringen mäter Amazon nu om AI-genererad kod fungerar och skapar värde. Tokenförbrukningen är inte företagets främsta prioritet.

Hur mycket kostade Tokenmaxxing företagen?

Tokenmaxxing kostade troligen Meta mer än 100 miljoner dollar på en enda månad och tömde Ubers årliga AI-budget på fyra månader. Uppskattningen för Meta bygger på enkel aritmetik. Enligt priserna i Claude Opus list-API (när nyheten kom ut) skulle 60,2 biljoner tokens kosta ungefär 900 miljoner dollar. Ett företag av Metas storlek förhandlar fram stora rabatter, men även då skulle kostnaden kunna nå nio siffror.

Uber ger den tydligaste bilden av kostnaden, eftersom företaget aldrig hade någon topplista. Företaget gav ungefär 5 000 ingenjörer agentiska kodningsverktyg utan någon kostnadsmodell. Inom en månad steg andelen ingenjörer som klassificerades som agentiska användare från 32 % till 84 %. Hela årsbudgeten tog slut på fyra månader .

CTO:n, Praveen Neppalli Naga, medgav att företaget var ”tillbaka vid ritbordet” när det gällde sina antaganden. De månatliga kostnaderna varierade mellan 500 och 2 000 dollar per ingenjör, och lösningen var rak: ett tak på 1 500 dollar per månad per kodningsverktyg och per ingenjör.

När ingenjörer som utför jämförbart arbete lägger ner så olika mycket tid visar denna variation att ingen hade definierat vad en bra användning egentligen innebar. Så varje ingenjör uppfann sin egen definition. Ubers COO Andrew Macdonald medgav detta och sa till Fortune att det var ”mycket svårt att dra en gräns” mellan AI-assisterad kod och användbara funktioner som faktiskt lanseras.

LeadDevs AI Impact Report visade att endast 19 % av teknikcheferna anser att tokenmaxxing är effektivt. 57 % av dem säger att det inte mäter det verkliga värdet.

Här är anledningen till att pengarna rör sig så snabbt: en agent som planerar en kodändring läser repositoriet, anropar verktyg, kör tester och försöker igen tills det lyckas. En enda loop kan förbruka tiotusentals tokens, och läsningar från prompt-cachen driver upp den siffran ännu högre.

Ekonomiteamen budgeterade för AI som om det vore en användarlicens. Men i själva verket fungerar det som molnbaserad datorkraft. Samma redovisningsglapp uppstår när team sätter ihop en AI-stack från flera leverantörer utan att någon tar ansvar för kostnaden. Det här är samma typ av problem som okontrollerad verktygsspredning, men på en högre nivå.

Vad är tokenminning?

Tokenminning är en metod som går ut på att minimera förbrukningen av AI-token och se låg förbrukning som ett mål. Som vi diskuterade i inledningen är det en överkorrigering som ger lika dåliga resultat. Namnet är en förkortning av ”token minimizing” och uppstod som en motreaktion mot tokenmaxxing. New York Times rapporterade om denna förändring hos flera företag.

Meta meddelade sina anställda att man skulle begränsa AI-användningen efter en ”exponentiell ökning” av kostnaderna. Uber satte ett tak för de månatliga utgifterna, Walmart införde begränsningar för verktygen, och både Amazon och Meta tog bort sina topplistor. Inom några veckor lärde samma företag som tidigare hade hyllat sina mest flitiga AI-användare nu alla att ransonera användningen.

Denna korrigering upprepar det misstag som den var avsedd att åtgärda. Goodharts lag förklarar det bäst: när ett mått blir ett mål upphör det att vara ett bra mått. Så om du sätter AI-tokenanvändning som mål kommer människor att hitta sätt att optimera för just det måttet, även om det innebär att den ursprungliga avsikten undergrävs. Goodharts lag varnar för tokenmaxxing och tokenminning.

Belöna ett team för att bränna tokens, så kommer det att bränna tokens som det inte behöver. Belöna ett team för att spara tokens, så kommer det att hoppa över den AI-körning som skulle ha upptäckt en bugg. Eller så delar det upp en grundlig session i tre billiga, som var och en ger ett ytligare svar. Båda teamen når sina mål för tokenanvändning, medan det faktiska arbetet blir sämre.

Kostnadskontroll i sig är inte felet. Precis som i exemplet med Uber är det månatliga taket på 1 500 dollar ett budgetbeslut som fattades efter att företaget hade förbrukat ett års budget på fyra månader. Men att sätta en utgiftsgräns löser bara ett ekonomiskt problem. Det ger inget svar på om de köpta tokenerna gav något användbart.

Lösningen är att skilja mellan två typer av siffror: signaler som du bevakar och resultat som du strävar efter. Tokenanvändning, införandegrad och andelen AI-skriven kod är signaler som visar vad som händer inuti systemet. De är användbara när du undersöker ett problem, men de är dåliga mål. Eftersom var och en av dem kan förändras kraftigt utan att kunden märker någon skillnad.

En organisation bör istället sträva efter resultat. De följer samma logik som alla välkonstruerade KPI:er för mjukvaruutveckling: koppla en tidig signal till det resultat den är avsedd att förutsäga. Shopifys konverteringsdashboard är mallen: samma data, men ingen placering på en topplista är kopplad till den.

Neil Dhar, senior vice president på IBM Consulting, beskrev hur förvirringen sprider sig i en essä om AI-kostnader.

#Tokenmaxxing har varit på alla förstasidor den senaste tiden. Organisationernas strävan att använda så mycket AI som möjligt, så snabbt som möjligt, och att göra användningen till ett mått på värde. Nu är det dags att betala räkningen. Eftersom AI-kostnaderna överstiger avkastningen är den naturliga reaktionen att skära ned. Men att bara skära ned på utgifterna löser inte det underliggande ROI-problemet.

Enligt IBM är lösningen att behandla användningen som en signal och koppla den till ett resultat som inte går att förfalska.

Innebär ökad tokenanvändning högre produktivitet?

Nej, hög tokenanvändning betyder inte hög produktivitet. De största tillgängliga datamängderna visar att de två utvecklas oberoende av varandra. Forskning från utvecklingsplattformen DX visar att införandet av AI närmar sig mättnad, medan de uppmätta produktivitetsvinsterna har stagnerat.

DX:s teknikchef Laura Tacho delade med sig av siffrorna. Bland utvecklare använder nu 92,6 % en AI-kodningsassistent minst en gång i månaden, och ungefär 75 % använder en varje vecka. AI skriver 26,9 % av produktionskoden. Ändå har den självrapporterade tidsbesparingen legat på ungefär fyra timmar per vecka i över ett år. Och den initiala produktivitetsvinnsten på 10 % ökade aldrig.

Användningen fortsatte att stiga medan resultaten förblev oförändrade. Alla mätvärden som enbart mäter användningen har rapporterat en framgång som aldrig inträffade.

Google Clouds DORA-rapport förklarar varför samma verktyg ger så olika resultat. Den visade att införandet av AI förbättrade leveranshastigheten men försämrade leveransstabiliteten. Rapporten beskriver AI som en förstärkare: den förstärker styrkorna hos välskötta organisationer och svagheterna hos de som kämpar.

DX:s egna data visar hur denna förstärkare fungerar. I en grupp på 67 000 utvecklare såg vissa organisationer antalet kundrelaterade incidenter fördubblas, medan andra halverade dem – trots att de använde samma verktyg under samma tidsperiod. Tacho lägger ansvaret där data pekar:

Det här är egentligen ett ledningsproblem. Hypen fick det att låta som att det automatiskt skulle löna sig att bara prova AI. Men hittills har de flesta verktygen använts för enskilda kodningsuppgifter. För att se verklig effekt måste vi använda AI på organisationsnivå, inte bara för enskilda uppgifter.

Det finns ett andra problem som ligger bakom det första: människor felbedömer hur mycket AI faktiskt påskyndar deras arbete. Det ideella forskningslaboratoriet METR genomförde en randomiserad kontrollerad studie. 16 erfarna open source-utvecklare löste 246 verkliga problem i kodbaser som de hade underhållit i genomsnitt fem år. Innan de började förutspådde utvecklarna att AI skulle göra dem 24 % snabbare. Efter att ha avslutat uppskattade de att det hade gjort dem cirka 20 % snabbare. Stoppuret visade att de var 19 % långsammare.

I en uppföljande uppdatering förklarade laboratoriet att det nästa experimentet stötte på urvalseffekter som man inte kunde korrigera för. Man uppgav också att utvecklare nu sannolikt verkligen arbetar snabbare med AI, främst tack vare agentbaserade verktyg. Vad som gäller: självrapporterad produktivitet är inte en ersättning för uppmätt produktivitet, och skillnaden mellan dem kan gå åt båda hållen.

Vad bör du mäta istället för tokenanvändning?

Mät istället resultaten på teamnivå och sedan på organisationsnivå, istället för tokenanvändningen. Betrakta tokenanvändningen som en kostnadssignal som ingen rankas efter. Det som spelar roll är de resultat som uppnås.

En praktisk regel att leva efter: koppla varje signal du publicerar till ett resultat som den inte kan blåsa upp. Ett team kan bränna tokens utan att leverera någonting. Däremot kan det inte fejka en sjunkande andel misslyckanden.

Denna struktur bygger på mätramar som ledande ingenjörer redan litar på. DORA mäter leveranshastighet och stabilitet, och dess slutsats att AI förstärker båda dessa faktorer är anledningen till att kombinationen är viktig.

DX Core 4 mäter fyra dimensioner: hastighet, effektivitet, kvalitet och affärspåverkan. Abi Noda och Laura Tacho utvecklade verktyget tillsammans med Nicole Forsgren och Margaret-Anne Storey, forskarna bakom DORA, SPACE och DevEx. De fyra dimensionerna står medvetet i motsatsförhållande till varandra.

Ett team som förbättrar det ena på bekostnad av det andra avslöjar omedelbart avvägningen. Inget av ramverken innehåller ett tokenmått, och inget av dem har lagt till något sådant.

Tre regler gör att kombinationen fungerar i praktiken:

Hur fastställer man en policy för AI-användning som medarbetarna inte kan manipulera?

För att fastställa en policy för AI-användning som medarbetarna inte kan manipulera bör du ta bort alla synliga siffror från den enskildes ställning och fatta fem beslut:

1. Bestäm vad siffran ska användas till innan du samlar in den

Varje mätvärde i policyn måste ha ett skriftligt syfte innan den första översikten publiceras. Shopifys topplista fungerade i början. Ledningen använde den för att inleda samtal med de som spenderade mest om vad de höll på att bygga upp. Siffran ledde till en utredning. Så snart samma siffra avslutar en utredning och drar slutsatser om en person istället för att ställa frågor om arbetet, förvandlas den till ett betyg. Och betyg blir något som ska hanteras.

Skriv ner tre saker per mätvärde:

Det är just den linje där inga åtgärder vidtas som kräver mest arbete, eftersom medarbetarna testar policyn mot den. Om det ärliga svaret på frågan ”vad händer när utgifterna ökar” påverkar någons ställning, har du skapat en resultattavla med extra steg.

2. Fastställ budgeten på teamnivå

En gemensam teambudget ersätter taket per person, och skillnaden ligger i beteendet, inte i redovisningen. Ubers månatliga spännvidd på 500–2 000 dollar bland ingenjörer som utför jämförbart arbete visar vad som händer utan en gemensam referenspunkt. Alla hittar på sin egen definition av vad som är rimligt. Budgetramar fungerar på samma sätt som alla andra försök att samla spridda AI-utgifter på ett enda ansvarigt ställe.

Med kuvertet får du tre saker som ett tak per person inte kan ge dig:

Beräkna storleken på det första budgetramen utifrån observerade data. Ta teamets genomsnitt för de senaste tre månaderna och lägg till ett utrymme för ett kostsamt projekt. En budgetram som fastställts på gissningar överskrids redan under vecka två, vilket visar alla att policyn bara är till för syns skull.

3. Synliggör den kostsamma vägen

Visa ingenjörerna kostnaden för varje körning istället för att sätta ett tak för vad de får spendera. Agentic-körningar som körs i en loop vid misslyckade tester är där budgetarna försvinner, vilket gör att ett fast tak hamnar i fokus. Ett annat alternativ är att visa kostnaden per körning för den ingenjör som utlöste den, utan att rapportera den vidare uppåt.

En ingenjör som ser hur en återförsöksslinga slukar 40 dollar kommer att åtgärda slingan. Däremot kommer en ingenjör som fruktar en rapport att sluta använda agenten helt och hållet, även i de fall då den kostsamma körningen var rätt beslut.

Shopifys säkerhetsmekanismer fungerar så här: systemet upptäcker avvikelsen, och den person som är närmast arbetet beslutar vad som ska göras. Insyn förändrar beteendet snabbare än ett tak gör, och det håller den dyra men korrekta driften tillgänglig när arbetet motiverar kostnaden.

4. Separera målet för AI-införandet från prestationsutvärderingen

Skriv ner uppsägningen, eftersom muntliga försäkringar inte håller i en uppsägningsvåg. Den Microsoft-ingenjör som beskrev hur de blåste upp sina egna användningsstatistik för The Pragmatic Engineer var inte ute efter någon belöning. De undvek att få en stämpel under ett år präglat av AI-relaterade uppsägningar.

Om människor tror att användningsdata hamnar på ett kalibreringsmöte kommer de att hantera data, oavsett vad någon säger högt.

Regeltexten behöver exakt två rader:

Se sedan till att ta hänsyn till båda. Den första ingenjören som upptäcker att användningsdata dyker upp i en granskning kommer att berätta det för alla, vilket bevisar att måttet är överflödigt.

5. Granska parningen varje kvartal

Fråga dig varje kvartal om varje diagnostik fortfarande förklarar det resultat den är kopplad till. Prissättning av modeller, cachelagringsbeteende och agentarkitektur förändras alla snabbare än en årlig planeringscykel.

Hur teamen använder AI för planering och rapportering förändras ständigt. Ett tokenantal som betydde en sak i januari betyder något annat i juni, efter två prissänkningar och en uppgradering av agenten.

Granskningen visar ärliga resultat per mätvärde: antingen förutsäger det fortfarande det förväntade resultatet, behöver kalibreras om mot nya priser, eller så har det slutat förklara någonting och tas ur bruk utan vidare. Det är teamen som motsätter sig detta mest. Det är dock viktigt, eftersom ett mätvärde som har förlorat sin betydelse är precis den typ av siffra som rankningslistornas era byggdes på.

Vanliga misstag som team gör när de mäter AI-införandet

De fyra vanligaste misstagen är att betrakta införandet som mållinjen, att lita på självrapporterade tidsbesparingar, att publicera individuella topplistor och att mäta hastighet utan att mäta stabilitet. Du kan upptäcka vart och ett av dem innan det blir kostsamt.

1. Att betrakta införandet som mållinjen

Införandeindikatorn visar 90 %, ledningen förklarar AI-initiativet avslutat, och ingen frågar vad som förändrats nedströms. DX:s data avslöjade denna fälla i stor skala: 92,6 % införande med en produktivitet som låg stilla på 10 %. Införandet bekräftar bara att verktygen nådde ut till människor. Det säger ingenting om vad verktygen förändrade.

Lösningen: Ta bort införandedialogen när lanseringen är avslutad och ersätt den med en kombination av signaler och resultat.

2. Att lita på självrapporterade tidsbesparingar

En undersökning visar att teamet sparar fem timmar per vecka, men cykeltiden har inte förändrats på två kvartal. METR:s test visar varför dessa två siffror inte stämmer överens: utvecklare som arbetade märkbart långsammare med AI uppskattade ändå en hastighetsökning på 20 % efteråt. Vad människor tror och vad klockan visar är två olika mått.

Lösningen: Behåll enkäten för utvecklarupplevelsen, där uppfattningen spelar roll. Använd systemdata för alla påståenden som rör tid.

3. Publicera en individuell topplista bara för skojs skull

Någon bygger upp det på en intern wiki under en eftermiddag, ger det lekfulla namn, och teamet har verkligen kul med det i ungefär tre veckor. Sedan tar incitamentet över. Metas Claudeonomics och Amazons Kirorank började båda som gräsrotsinitiativ för skojs skull. Båda företagen lade ner dem när spelandet växte sig större än entusiasmen.

Lösningen: Sammanställ data på teamnivå, annars ska du inte skicka ut den.

4. Att mäta hastighet utan att mäta stabilitet

Genomströmningen ökar, alla jublar, och antalet incidenter stiger på ett annat teams instrumentpanel. DORA-rapporten identifierade just denna klyfta: hastigheten förbättras medan stabiliteten försämras. Genom att hålla de två siffrorna på separata instrumentpaneler förblir problemet osynligt.

Lösningen: Placera felfrekvensen för ändringar på samma skärm som hastighetsmätvärdena, inte i en separat tillförlitlighetsgranskning som ingen korsrefererar till.

Så här följer du upp AI:s påverkan i ClickUp

För att följa AI:s påverkan i ClickUp ska du mäta resultaten i direkt anslutning till själva arbetet: de uppgifter, sprintar och leveranser som AI:n var tänkt att påskynda. De flesta token-dashboards finns i en leverantörskonsol, långt bort från det arbete de beskriver. Genom att flytta resultatmätningarna in i arbetsytan överbryggas den klyftan.

Kopplingen mellan signal och resultat från tidigare speglas direkt på plattformen:

Håll koll på antalet token utan att betygsätta människor

Hela historien kan sammanfattas i en regel: använd token-data för att ställa frågor, aldrig för att betygsätta människor. Shopify frågade ”vad bygger våra största kunder?” och upptäckte okontrollerade agenter och infrastrukturfel. Meta och Amazon frågade ”vem använder AI mest?” och fick falska uppgifter, slösade bort miljoner och döda topplistor.

Gör därför tre saker under detta kvartal. Flytta tokenövervakningen till teamnivå och ta bort allt som visar en enskild persons namn. Skriv in i policyn att användningsdata aldrig får påverka prestationsutvärderingen. Och placera ett kvalitetsmått (förändringsfelprocenten är det enklaste) på samma skärm som alla hastighetsmått du rapporterar.

Om du vill ha den skärmen bredvid själva arbetet istället för i ett separat rapporteringsverktyg kan du komma igång med ClickUp gratis och bygga upp instrumentpanelen innan du behöver den.

Vanliga frågor om Tokenmaxxing (FAQ)

Vad är 30-procentsregeln för tokenmaxxing?

Det finns ingen officiell ”30-procentsregel” som är specifik för tokenmaxxing. Uttrycket är oftast en förkortning för två separata iakttagelser som människor blandar ihop: att AI tenderar att höja den uppmätta tekniska produktiviteten med ungefär 10 %, inte 30 %, och att utvecklare rutinmässigt förutspår vinster på omkring 20–30 % som inte förverkligas. Betrakta varje fast procentsats som en indikator att undersöka, aldrig som ett mål att uppnå.

En miljon token motsvarar ungefär 750 000 ord i engelsk text, eftersom ett token i genomsnitt motsvarar ungefär tre fjärdedelar av ett ord. Kostnaden beror helt på modellen och fördelningen mellan indata och utdata. Med 2026 års priser för frontier-modeller varierar den från några dollar till några tiotal dollar per miljon. Agentiska sessioner förbrukar snabbt miljoner token eftersom varje loop läser om kontexten, och läsningar från prompt-cachen bidrar till antalet.

”Tokenmaxxing” kombinerar ”token” med internet-suffixet ”-maxxing”, vilket betyder att maximera en egenskap. Begreppet spred sig i ingenjörskretsar i början av 2026 efter att interna token-topplistor hos Meta och Amazon läckt ut till pressen. Business Insider kallade det ”den nya AI-debatten i Silicon Valley ” i april 2026. Offentliga topplistor som Viberank och tokenmaxxing.sh tog sedan till sig begreppet och rankade enskilda utvecklare världen över efter API-användning.

I stort sett, ja. Fortune förklarade att tokenmaxxing var över i maj 2026 efter att Meta, Amazon, Microsoft och Uber drog tillbaka eller lade ner sina token-topplistor. LeadDevs AI Impact Report visade att endast 19 % av de tillfrågade anser att tokenmaxxing är ett effektivt sätt att mäta AI-värde, medan 57 % säger att det misslyckas fullständigt. Offentliga topplistor för hobbyanvändare finns kvar, men som ett spel, inte som en ledningsmetod.

Det finns ingen etablerad riktlinje. Vid Ubers införande varierade de månatliga kostnaderna mellan 500 och 2 000 dollar per ingenjör innan företaget satte ett tak på 1 500 dollar per verktyg. Nvidias VD Jensen Huang har hävdat att en ingenjör som tjänar 500 000 dollar bör förbruka 250 000 dollar i tokens per år, men det är troligen en provokation, inte en standard. Undersökningar visar på stora variationer mellan jämförbara arbetsuppgifter, vilket innebär att ingen har definierat hur en lämplig användning ser ut.

Vibe-kodning är ett arbetssätt: att delegera implementeringen till en AI-agent och styra utifrån resultatet. Tokenmaxxing är ett sätt att mäta: att behandla de tokens du förbrukar som ett bevis på produktivitet. Du kan vibe-koda effektivt eller slösaktigt; tokenmaxxing belönar den slösaktiga versionen eftersom den endast räknar förbrukningen. Företag som satte tak på tokens för att stoppa tokenmaxxing straffade ofta legitimt agentiskt arbete i processen.