Your token level has been used. Et nyoppdaget problem introdusert på denne siden av Covid. Fenomenet med at du har brukt opp alle tokens tilgjengelig i din betalte plan for AI agenter. På samme måte som når varsellampen for lite drivstoff tenner på bilen, eller da man i nittenhundreoglengesiden hadde rasjonering på strøm. Selve konseptet er med andre ord gammelt, men for vår generasjon er det på nytt kontekstualisert rundt et nytt domene.

Men først; Hva er egentlig tokens, og hvorfor snakker vi om det med tanke på AI agenter? I en AI modell er målet å få ut generert innhold (les: tekst, bilde, video) og måten man gjør det på er å prosessere tokens. Når en modell mottar en input prompt så oversettes denne til tokens via en tokenizer, og vise verca for output. AI modellen vil derfor ta imot en viss mengde input tokens, og deretter gi ut en annen mengde output tokens. Output tokens er som regel mer kostbart enn input tokens, men for enkelhets skyld så behandler vi de likt for nå. Ved å spørre ChatGPT om "Kan du skrive et dikt om sommer?" (A) så bruker vi ganske få tokens for input. Ord i et setning og tokens er ikke en-til-en, men la også gjøre denne forenklingen (det er ikke så fryktelig feil heller). Vi har brukt 7 tokens til input. En enkel model vil svare raskt og uten å "tenke" noe ala: "I sommer skal jeg telte, surfe og svømme, samt spise mat og noen glass jeg skal tømme" (B), som resulterer i 17 output-tokens og 24 tokens totalt. Om diktet (outputen) hadde vært dobbelt så langt, så ville totalt antall tokens vært 41. Det vi forstår er at en modell som genererer mye output vil også «bruke» mange tokens i ressurskabalen vår.

Ganske enkelt, så hva er egentlig problemet? Da ChatGPT (GPT-3.5) ble lansert så var dette en relativt enkel modell sammenlignet med hva vi har i dag. Det fulgte eksempelet over her ganske rett frem. En samtale med en AI modell følger et relativt dumt mønster, men det funker. I eksempelet har vi nå spurt A og fått svar B. Ved et oppfølgingsspørsmål i samme samtale, "bytt ut aktivitetene med noe man gjør innendørs" (C), så fôres hele samtalehistorikken til AI-modellen, før vi får et nytt svar "I sommer skal jeg pusle, rydde og drømme, samt spise mat og noen glass jeg skal tømme" (D). Dette kan illustreres slik

• Spørsmål 1: "Kan du skrive et dikt om sommer?"
  • Input: A - 7 tokens
  • Output: B - 17 tokens
  • Totale tokens bruk: 24 tokens
• Spørsmål 2: "Bytt ut aktivitetene med noe man gjør innendørs"
  • Input: A + B + C - 32 tokens
  • Output: D - 17 tokens
  • Totale tokens brukt: 24 fra forrige spørsmål + 49 nå = 73 tokens

Vi ser at oppfølgingspørsmålet allerede har mer enn 3 ganger så mange inputtokens som det opprinnelige spørsmålet. Ved forlengelse av samtalen vil tokenbruken fort gå i taket.

Vi skjønner også raskt hvorfor det å si "Takk" som en avsluttende kommentar kan bli ekstremt dyrt. La oss fortsette kjeden:

• Spørsmål 3: "Takk"
  • Input: A + B + C + D + "Takk" = 50 tokens
  • Output: "Bare hyggelig" - 2 tokens
  • Totale tokens brukt: 73 tokens fra før + 52 tokens nå = 125 tokens

Den avsluttende kommentaren i samtalen gjorde at vi betalte prisen av forrige spørsmål en gang til. Om modellen er litt sleip så får man en hel avhandling (og ikke kun "bare hyggelig") tilbake som gjør at vi betaler enda mer.

Context-vindu

Til tross for at vi enkelt kan se hvordan tokenbruken raskt mangedobler seg, så var det likevel "ingen" som snakket om dette i 2022 med ChatGPT. Uavhengig av hvilken AI model man har for seg, så er potensialet egentlig å bruke uendelig med tokens. Men med dagens modeller er det vesentlig lettere å brenne enorme mengder sammenlignet med før. Hvorfor det? Med GPT-3.5 var vi ganske begrenset både på hvor mye context modellen klarte å ta inn, men spesielt på hvor mye tokens den kunne generere ut. Fra kjeden over er det tydelig at antall output-tokens som genereres påvirker input i neste omgang. I dag har vi såkalte reasoning-modeller, som itererer flere ganger for å se om modellen svarer på det som det faktisk ble spurt om - den "tenker" - før den leverer et svar. I eksempelet vårt kan vi derfor se for oss å måtte utvide flyten ytterligere. Vi spør på nytt "Kan du skrive et dikt om sommer?", modellen starter reasoning som i et veldig enkelt scenario kan utarte seg slik "Brukeren spør meg om å skrive et dikt om sommer, da burde jeg nevne aktiviteter for varmt vær, samt forsøke på et rim" (T, 23 tokens). Reasoning tokens går rett inn i bunnlinja (faktureres som dyre output-token), og kan potensielt bruke enormt med tokens selv om den returnerende outputen er ganske kort.

• Spørsmål 1: "Kan du skrive et dikt om sommer?"
  • Input: A - 7 tokens
  • Reasoning: T - 23 tokens
  • Output: B - 17 tokens
  • Totale tokens bruk: 47 tokens

Som om dette ikke er nok, så er integrasjonen med AI modellene gjort mye smartere (og det er nå vi kan begynne å kalle dette for agenter i stedet for modeller), og verktøy som MCP, skills, agent-instructions, rules etc hentes i dag automatisk inn i input-contexten. Som er bra! Fordi det hjelper agenten i å utføre oppgaven riktig fra start og unngå ekstremt lange samtaler fordi den ikke følger reglene fra start. Men kostnaden er fremdeles at antall tokens skyter til værs, og problemet med dèt er at tokens ikke er gratis. Leverandørene tar derfor betalt for bruk, enten pris per token opp til et visst nivå eller en pakkepris med et visst antall tokens til en gitt pris.

Den maksimale contexten modellene kan håndtere i form av input og output har mangedoblet seg fra den spede begynnelse til i dag - og den kommer bare til å øke

Overforbruk har blitt en klassiker og forklares best med

Token usage limit reached

Du har brukt opp alle tokens du har betalt for, og må vente til neste periode hvor du får en ny runde med tokens tilgjengelig - eller betale mer. Så hvorfor skjer dette? En enkel analogi å sammenligne med her er en elbil. Hovedformålet til en bil er å legge fra seg distanse, og for å gjøre det lader man batteriet og fordeler strøm utover kjøreturen. Du kan kjøre fort og bruke mye strøm, eller du kan kjøre sakte og bruke lite. Men målet vil alltid være å komme frem raskest mulig, på en trygg måte som følger reglene, uten å gå tom for strøm. Når bilen står der uten strøm halvveis på distansen er det enkelt å starte retrospekt; Burde kanskje ha ligget bak, og ikke foran, den bilen på E6? Kunne kanskje greid meg med bare 5min forvaltning av bil? Dette gjelder rekkeviddeangst på elbil, og burde også gjelde tokenbruk på AI agenter.

Når man bruker opp tokens, så har man brukt opp ressursene sine, men det sier ingenting om måten man har brukt de opp på. I fjor vår gjestet jeg Aksel Øverns podcast hvor vi snakket om rett modell til rett bruk. Etter hvert som AI modellene blir kraftigere og kraftigere (les: dyrere og dyrere), så gir dette også desto større gevinst. Opus 4.7 er ganske nylig lansert, og viser seg som en av de (om ikke den) beste modellene til å generere kode. Å ha tilgang til en slik modell er viktig for å kunne effektivisere og generere de beste løsningene, men det kommer med en pris. Pris på AI agenter følger to variabler, kost per tokens - men også hvor mange tokens som blir brukt for å komme frem til svaret. Opus 4.7 er helt i toppen på begge to.

Oversikt over forskjellige modellers tokenpris. Vi ser at prisen på output er vesentlig større enn input, noe som igjen gjør at reasoning skyter i pris

For de som har fulgt med så har Opus 4.7 Fast mode nettopp blitt lansert i Beta, med prisen på 6x standardprisen til Opus 4.7. Det betyr svimlende $30 per M input token, og $150 per M output token. Dette begynner å bli veldig dyrt.

Redusere tokenbruk - uten å redusere kvalitet

Problemet vårt begynner å materialisere seg selv. Ukritisk bruk av AI interaksjon kan fort bli dyrt, enten i form av at man bruker opp rasjoneringen sin tidlig, eller at fakturaen har et par ekstra sifre. Men løsningen vår er dessverre ikke bare en enkel bryter, det er litt mer komplekst enn som så. Vi ønsker det beste resultatet, men med lavest mulig kostnad. Misforstå meg rett, målet er ikke å aldri bruke de dyre (og beste) modellene, men heller å ha en sunn tilnærming til hvordan man kan redusere kostnadene i sitt daglige arbeid uten at det går på bekostning av kvalitet. For reduksjon av kostnader har vi to variabler å gå etter - enten å ha lavere kostnad per token, eller å redusere antallet.

Redusere tokens

Redusere inputen og/eller output er en åpenbar strategi for å kutte kostnad. Unødvendige ord og fluff i det originale spørsmålet eller svaret hjemsøker oss i resten av samtalen som sett i eksempelet over. For noen måneder tilbake så tok caveman-skillen av på internett, da den instruerte agenten til å uttrykke seg på et svært begrenset språk lignende en huleboer. Tokenbruken gikk drastisk ned, samtidig som kvaliteten holdt seg overraskende godt. Slike tiltak oppleves gjerne som svært effektive ettersom du ikke trenger å endre arbeidsflyten for å oppnå bedre resultater. Tilsvarende approacher har vært å be agenten snakke på kinesisk ettersom det er mer token-effektivt enn engelsk.

Selv om denne løsningen var spennende, så kan det sammenlignes med å behandle symptomene i steden for sykdommen. I tillegg påvirket den heller ikke reasoning-delen, så nedslagsfeltet var noe smalt. For å helbrede sykdommen, må vi være mer bevisst på arbeidsflyten. Her er det ikke så mange silver bullets dessverre, men noen kjøreregler kan være greit å tenke over. Vi har sett hvordan en samtale akkumulerer contexten ved at hele samtalen tas med i neste input. Å ha et bevisst forhold til samtalelengden er derfor viktig, og kan enklest fikses ved at hver nye oppgave fortjener en ny agent (les: samtale). Om en samtale drar seg ut kan man også be om et sammendrag av den oppbygde contexten, for deretter fortsette samtalen i en ny samtale for å drepe den eksponentielle veksten.

"Man må bruke energi, for å få energi" er et kjent ordtak. I agentverden kan vi driste oss til å si "man må bruke tokens, for å redusere tokens". Poenget her er å specke opp regler og instrukser ved bruk av skills, instruksjoner, agents.md og lignende. Dette gjør forutsetningen for at agenten kan levere riktig svar på kortere tid. Det koster ekstra tokens i starten, men kan redusere den totale bruken. I tillegg til at det øker effektiviteten til brukeren selvsagt. Skills lastes inn av agenten automatisk når den skjønner at det bør brukes, mens unødvendige MCP tools-call fyller opp contexten svært raskt. Optimalisering av disse er også en smart måte å redusere på.

Å holde oversikt over tokenbruk for hver agent blir lettere og lettere. Her er et skjermbilde fra Cursor som på ganske elegant vis viser fordelingen av context-bruken. Tilsvarende verktøy som feks Claude-devtools er tilgjengelig for Claude.

One shot er noe man hører om, men som er en risikabel strategi. One shot er en beskrivelse av at man forsøker å få agenten til å løse et stort problem eller oppgave med èn eneste prompt. Med tiltakene over øker man sannsynligheten, men risikoen for å svi av hele ukens tokens-kvote uten det resultatet man egentlig så for seg er tilstede. Det blir som å sette seg i el-bilen på vei til hytta og "satse på" at nøkkelen ligger i hanskerommet. Om de ikke var der likevel risikerer man å ha brukt opp hele bilbatteriet og må vente på at den trege stikkontakt-laderen tilbakefører "tokens". En bedre approach (i alle fall nå når jeg skriver denne bloggen) kan være å dele opp problemet og sørge for at delproblemene løses korrekt med mindre bruk av tokens.

Redusere pris per token (bytte modell)

En noe mer kontroversiell (eller kanskje ikke?) fremgangsmåte er å være mye mer bevisst på hvilken modell man bruker. Uansett hva man jobber med, så er det forskjell på kompleksiteten av oppgaven. Hvis du skal bygge en pallekarm i hagen, så trenger man kanskje ikke å involvere arkitekter fra Snøhetta. Akkurat den samme approachen bør man ha med AI agenter. I tillegg vil man gjerne oppnå effekten av å få raskere svar, da modellen bruker mindre tid på å respondere. Vinn-vinn, så lenge du har tatt hensyn til kvaliteten på svaret eller kompleksiteten med oppgaven. Burde du bruke samme modell til å opprette en plan, som den modellen som faktisk implementerer? Trenger du en reasoning-modell for å oversette UI-et ditt til et annet språk?

Det finnes tjenester som automatisk bytter modell basert på omfanget av oppgaven. Noen kommer som plugins, andre kommer integrert. Det som er viktig å være bevisst på er at de integrerte ikke nødvendigvis trenger å velge den som er best for deg. Cursor, for eksempel, har denne funksjonaliteten innebygd. Uten å konspirere for mye, så vet man at de som selskap får større margin ved å bruke enkelte modeller over andre. Å styre "auto"-mode mot det som er mest prisgunstig for dem, og heller la ulempene havne på brukeren, kan være noe man bør ha i bakhodet.

AI-terminalen Warp tilbyr også denne modusen, men har også en veldig enkel oversikt over hvilke parametre den enkelte modellen du ser på. Dette trenger ikke være en 100% rett visning, men det gjør at man som bruker mye enklere kan ta bevisste valg. Slike oversikter er mulig å feiltolke dog, som vi kan se litt på skjermbildet her. TIlsynelatende er ikke Opus 4.7 helt øverst på kostnad, men det er først og fremst takket være dem selv etter at Fast mode ble tilgjengelig og 6-doblet prisen. Trenden vi uansett ser er at tokens på de kraftigste modellene bare blir dyrere og dyrere.

Et annet veldig interessant aspekt er å se på hvor mange tokens de forskjellige modellen bruker for å løse den samme oppgaven. Da Opus 4.7 kom ut så ble den også lansert med en ny tokenizer. Dette skapte umiddelbar reaksjon, da det raskt ble tydelig at antall tokens så ut til å øke ganske mye. Dette er også nevnt i dokumentasjonen av modellen, og her kommer det frem at 4.7 kan bruke opptil 35% mer enn den forrige modellen (Opus 4.6). Det sier seg selv at selv om tokenprisen i tabellen over her viser det samme for begge disse modellene, så blir prisen ganske forskjellig om man bruker 35% mer av de. En svært enkel test med å spørre de to nevnte modellene med "List up the differences between React 18 and 19" viser følgende context-bruk:

Tabellen viser at Opus 4.7 absolutt bruker mer tokens i et reelt utviklingsmiljø definitivt resulterer i forskjellig tokenbruk. Merk at dette er en svært enkelt test, og viser absolutt ikke det hele bildet. Outputen kan for eksempel være veldig forskjellig i kvalitet.

Self host

Å kjøre modeller selv fjerner hele kostnadsbildet på tokenbruk (man må i steden betale for strømmen som kreves for å kjøre modellen, men la oss ikke tenke på det nå). Men problemet med dette er at de modellene man kan kjøre selv, er gjerne sammenlignbart med de modellene som uansett er ganske billige. De beste modellene der ute er ikke tilgjengelige for oss å kjøre selv, og det er gjerne disse vi ønsker å bruke litt her og der. Self host bare for å redusere kostnader er nok derfor kanskje ikke det mest effektive tiltaket man kan gjøre i dag - dessverre. Men samtidig er det viktig å følge med på hvordan intelligensen på disse modellene utvikler seg videre. Da DeepSeek sjokkerte verden i januar 2025, så var det nettopp dette som skjedde. En open source modell leverte plutselig de beste resultatene. Om dette hadde skjedd i dag, så hadde self-host vært et åpenbart tiltak.

Konklusjon

Så hvorfor er dette egentlig verdt en bloggpost? Jo, fordi det er store kostnader å spare om man er litt smart på valgene sine. Både i form av å "aldri gå tom for tokens", men også fordi hvert token koster penger. Vi har sett at kostnaden av en AI agent defineres av to variabler, pris per token og antall token brukt. Etterhvert som utviklingen fortsetter, så skal man ikke se bort fra at dette blir helt sentrale kostnadsoptimaliseringer alle selskaper og privatpersoner må gjøre. Som en bonusmotivasjon, så korresponderer også tokenbruk veldig godt med bruk av strøm. Rett valg av modell vil derfor også gi bedre miljøbevisste valg!

Disclaimer: I artikkelen har jeg tatt noen snarveier for å få frem forståelsen på hvordan tokens brukes. I realiteten er tokens-fakturering mye mer komplekst enn som så. Man har cached input tokens, cached output tokens (som en sped start for å liste opp noe) som gjør at det ikke er like enkelt å regne ut alle kostnader. Uavhengig av dette så står fortsatt prinsippet om at ufornuftig bruk av tokens resulterer i unødvendig høye kostnader