.avif){kind=logo}
I mai 2026 brant et stort norsk selskap gjennom sitt månedlige GitHub Copilot-budsjett mye raskere enn ventet. Jo flere kolleger jeg snakker med, desto oftere hører jeg lignende historier. Mønsteret går igjen, og det kommer bare til å bli mer utbredt.
Tre ting har skjedd samtidig denne våren. GitHub Copilot legger om til forbruksbasert prising 1. juni 2026. Claude Opus 4.7 (og nå nylig Opus 4.8) har blitt langt dyrere å bruke på Copilot på to måneder: hver forespørsel telles nå som 27 vanlige forespørsler mot kvoten din, mot 7,5 ved lansering. Anthropic har samtidig endret tokenizeren slik at samme input kan bli opptil 35% flere tokens, uten å endre listeprisen. De tre punktene forsterker hverandre.
For utviklere som har bygd agentiske arbeidsflyter inn i hverdagen, betyr dette at den marginale kostnaden ved hver beslutning du delegerer til en agent, har gått fra "neglisjerbar" til "noe noen følger med på". Det er en synliggjøring av hva inferens, altså det å la en modell kjøre og produsere et svar, faktisk koster, og en kvittering for vanene vi rakk å bygge oss mens prisen var lav.
Dette innlegget handler om hvordan jeg tenker på den nye token-økonomien, ikke som et kostnadsspørsmål, men som et spørsmål om hvor mange velinformerte valg og parallelle hypoteser teamet ditt får ut av tokenene det bruker, forutsatt at teamet er rigget for å bruke dem godt. Linsen er bevisst smal: jeg velger her å skrive om de konkrete grepene utviklere selv kan ta i sin daglige praksis.
Hopp videre om du vet det. En token er ikke et ord eller et tegn, men en “underordsbit” modellen leser: vanlige ord blir gjerne ett token, sjeldne ord splittes i flere. Det er disse bitene du faktureres for.
Tre nyanser er verdt å ta med inn i resten av innlegget. Input-tokens (det du sender inn) og output-tokens (det modellen genererer) prises ulikt, og output koster typisk rundt fem ganger så mye som input. Det er en stor del av forklaringen på hvorfor verktøy som komprimerer modellens svar har konkret økonomisk verdi. Reasoning-tokens, altså modellens skjulte tankerekker når den jobber i resonneringsmodus, faktureres som output-tokens hos både OpenAI og Anthropic, selv om de ikke vises i svaret du leser. Og hver leverandør har sin egen tokenizer, slik at samme tekst kan bli ulikt antall tokens hos Anthropic, OpenAI og Google. Det er nettopp den mekanikken Anthropic justerte i Opus 4.7 og fikk ca. 35% effektiv prisøkning uten å røre listeprisen.
Norsk havner forøvrig rundt 1,7–1,9 tokens per ord, mot engelsk på ca. 1,2. En liten språkskatt, ikke en stor, men verdt å vite om når du regner på forbruket.
Historien om selskapet som går tom for tokens før måneden er over er en av mange. Microsoft kansellerte sine Claude Code-lisenser i Experiences and Devices-divisjonen seks måneder etter pilotering, og dirigerer ansatte over på Copilot CLI innen 30. juni 2026. Uber sin CTO forteller at selskapet brant gjennom hele sitt AI-budsjett for 2026 på fire måneder. Goldman Sachs anslår 24x vekst i samlet token-konsum innen 2030, drevet av agentiske systemer som bruker opptil 1000x flere tokens per oppgave enn en standard LLM-forespørsel.
Pris per token faller, mens samlet forbruk eksploderer. Det er ingen motsetning. Agenter er vesentlig dyrere å kjøre enn en chat som varer i noen få samtalerunder.
I det norske selskapet jeg nevnte innledningsvis ble ekstra budsjett lagt til og brukt opp samme dag, ifølge intern kommunikasjon. Ledelsen innførte derfor en månedlig cap per lisensiert bruker inntil videre. En ansatt påpekte at beløpet var altfor lavt, at de ville gå tomme innen midten av måneden selv om folk var bevisste på token-bruken, og at et realistisk budsjett lå nærmere fire til fem ganger høyere. Hva er poenget med å fortelle deg dette, tenker du kanskje?
Det nye er ikke at ledelsen har en mening om hva verktøyene koster; sky-budsjetter, lisenstak og kvoter på infrastruktur har lenge vært en del av utviklerhverdagen. Det nye er granulariteten: nå handler det i større grad om den enkelte utviklerens prompting-vaner i nær sanntid. Den dynamikken kan i verste fall bremse utviklingshastigheten, ikke øke den. Og utviklere som har valget, kan begynne å se seg rundt etter andre arbeidsplasser.
Det første halvannet året med moderne agentisk koding har vært kraftig subsidiert, men subsidien er ulikt fordelt, og det er verdt å være presis på hvordan. Anthropic og OpenAI priser fortsatt sine egne førstepartsprodukter (Claude Code via Claude-abonnementet, Codex via ChatGPT-abonnementet) et godt stykke under det reelle inferensregnskapet. Grunnen til det er ganske enkelt at markedet skulle vinnes, vanene skulle etableres, og byttekostnaden skulle bygges opp.
Tredjepartsverktøy som GitHub Copilot lever derimot oppå API-endepunktene til de samme labene, og API-prisene ligger vesentlig høyere enn det en sluttbruker betaler i et førstepartsabonnement. Når Anthropic justerer API-prisen sin på Opus-modellen eller endrer tokenizeren, slår det rett inn i kostnaden GitHub må videresende til lisenskunden sin. Det er hovedforklaringen på hvorfor det er organisasjonene som bruker Copilot-lisenser som først merker at regningen kommer, mens utviklere som jobber direkte på en Claude- eller ChatGPT-konto foreløpig sitter i den subsidierte gangen.
Den asymmetrien blir neppe varig: før eller siden må også førstepartsproduktene reflektere reell inferenskostnad. Men akkurat nå er valg av plattform en av de største enkeltfaktorene for hva tokens faktisk koster deg.
Maxim Salnikov hos Microsoft skrev nylig en guide som setter dette i en presis ramme. Hans poeng er at spørsmålet de fleste team stiller seg nå, "Hvordan kutter vi token-forbruket?", er feil spørsmål. Det riktige spørsmålet er: "Hvordan får vi mer ut av tokenene vi bruker?"
Et team som jakter på lavest mulig token-forbruk, optimaliserer mot en kostnadslinje. Den optimaliseringen har et nullpunkt, nemlig at den billigste prompten er den du aldri sender. Et team som jakter på høyest mulig avkastning per token, har ikke det samme nullpunktet; du må faktisk bruke tokens for å produsere noe. Det kan høres ut som to fremstillinger av samme problem, men de drar adferden i ulike retninger. Det første resulterer i en gnien token-kultur, der utviklere føler skyld for å bruke verktøyene, velger en svakere modell enn oppgaven fortjener, og kutter kontekst som kanskje var nødvendig for å løse problemet. Det andre oppfordrer til disiplin: bedre prompts, klokere modellvalg per oppgave, reflekterte tanker rundt kontekst, bedre verktøykasse for utviklerne.
Salnikovs sentrale påstand er at å kaste en lat og tvetydig prompt mot en dyr modell og prøve igjen om det feiler var en levedyktig strategi når tokens var tilnærmet gratis, men den slutter å være det i det øyeblikket den marginale kostnaden synliggjøres. Den løses ikke ved å gamble mindre, men ved at hvert agent-kall lander mer presist.
Med grunnlaget på plass har jeg noen konkrete råd. De henvender seg særlig til deg som kjenner på at kontekstvinduet ikke alltid strekker til, eller som stadig føler at du må optimalisere for token-bruk.
Det er en mekanikk i agentiske flyter som mange team ikke tenker over. Hvert steg en agent tar bærer en liten sjanse for å gå feil, og fordi stegene bygger på hverandre, legger ikke den risikoen seg sammen, den ganges. Jo lengre kjeden er, desto større er den samlede sjansen for at noe glipper underveis. En agent som løser ti steg upåklagelig, kan fortsatt rote seg bort på steg førti, og da kan alt som kommer etter feilen arve et galt handlingsmønster.
En nyttig måte å se det på er at hver modell har en horisont: en oppgavelengde der den fortsatt holder kvaliteten oppe, og et punkt forbi der påliteligheten faller bratt. METR måler nettopp dette, altså hvor lange oppgaver en agent klarer før treffsikkerheten ryker, og finner at horisonten har doblet seg omtrent hver syvende måned. Lange, sammenhengende agentiske oppgaver er nettopp den aksen frontier-labbene konkurrerer på nå.
Her ligger også svaret på hvorfor man ikke bare kan "bruke en billigere modell". Forbedringene konsentreres i toppmodellene, og avstanden mellom en dyr og en billig agent vokser nettopp langs denne horisonten. En billigere modell betyr derfor ikke bare litt lavere kvalitet per kall; den har en kortere horisont og treffer pålitelighetsstupet tidligere på akkurat den samme oppgaven. Og hver kjøring som detter utfor koster nye tokens i tillegg til menneskelig tid for å rydde opp. Det er her prinsippet om å avdekke feil tidlig, kjent fra testing og sikkerhet, blir ekstra viktig når du setter sammen agentiske flyter, et poeng jeg kommer tilbake til lenger ned.
Av alle optimaliseringer er to mer betydningsfulle enn alle andre kombinert:
Konteksten råtner også over tid (”context rot”). Når kontekstvinduet fylles opp forbi halvparten, begynner modellen å vektlegge de siste meldingene på bekostning av systemprompten og de opprinnelige instruksjonene dine. Slik er modellen trent. Konsekvensen er at agenten gradvis glir bort fra målet du definerte i starten, uten at noen varsler deg om det.
En /clear for hver ny oppgave er derfor ofte bedre enn å kompaktere konteksten. Kompaktering frigjør plass ved å oppsummere samtalen, men en risikerer da å tape mellomliggende resonnement og nyanser. En ren ny oppstart med et nøyaktig formulert mål er som regel både billigere og mer presist.
I praksis betyr dette at jeg nylig har gjort to håndfaste endringer.
For det første har jeg blitt en mer aktiv bruker av OpenAI-modellene. Jeg var tidligere nesten utelukkende på Anthropic. GPT-5.4 og GPT-5.5 har imponert nok til å bli en fast rotasjon inn i min workflow, særlig for oppgaver der jeg verdsetter forutsigbar instruksjonsfølging fremfor brainstorming og sparringssesjoner.
For det andre har jeg eksperimentert mer med reasoning-nivåer avhengig av oppgaven som skal gjøre. GPT-5.5 på lav reasoning er en kostbar modell brukt billig, men i implementasjonsfasen, der jeg allerede har en nøye definert spec og bare trenger velkonstruerte små endringer, gir det høyere utviklingshastighet uten å ofre den delen av modellens kapasitet jeg faktisk trenger.
Så langt har vi snakket om atferdsendringer: hvordan du velger modell, strukturerer kontekst og organiserer arbeidsflyten. Men det finnes også verktøy som sparer tokens uten at du trenger å endre måten du jobber på. To av dem fortjener omtale fordi de illustrerer to ulike retninger av samme problem.
rtk ("Rust Token Killer") sitter mellom agentens Bash-verktøy og selve shell-kommandoen. Den filtrerer og komprimerer output før den treffer kontekstvinduet. git status blir rtk git status via en pre-tool hook, og agenten merker ingenting.
Mine egne tall etter ca. 164 000 kommandoer på fem uker: 29,6 millioner tokens spart, hvilket tilsvarer 85% økt effektivitet i token-forbruk. Den varige gevinsten kommer fra hverdagslige mønstre: curl-kall som henter store assets, ps aux, gh pr diff og fillesing via rtk read. Det er den typen støy som stille akkumulerer i kontekstvinduet uten at du legger merke til det.
caveman er den filosofiske motsatsen: en agent-skill som instruerer modellen til å komprimere sin egen output, omtrent som å snakke som en huleboer. Forfatteren rapporterer ca. 65% reduksjon i output-tokens på tvers av et benchmark-sett, men med et viktig forbehold: caveman påvirker bare output-tokens, ikke reasoning-tokens. Jeg bruker den ikke aktivt selv, men jeg tar den med fordi den illustrerer output-siden av disse mekaniske endringene man kan gjøre i arbeidsflyten sin. Oppsummert sier rtk "ikke send unødvendig tekst inn", mens caveman sier "ikke generer unødvendig tekst ut".
Hver test, linter, type-sjekker og sikkerhetssjekk som koden må passere er et deterministisk gjerde rundt agentens output. Hver passerende test nullstiller feilraten for den egenskapen testen dekker, gitt at testene er ferskvare og av høy kvalitet. Hvis teamet ditt allerede jobber agentisk, men uten bevisst fokus på testkvalitet og testdekning, bør det stå på agendaen i nær fremtid. Ikke bare fordi testing er god skikk i seg selv, men fordi agentisk utvikling uten et solid testfundament forsterker feil raskere enn manuell utvikling noen gang gjorde.
Som en naturlig forlengelse av dette lønner det seg å rigge selve kodebasen for agenten. Hold dokumentasjon fersk og nær selve koden, ikke gjemt i en wiki agenten aldri åpner. Plasser domenespesifikk kontekst der arbeidet faktisk skjer, gi modulene tydelige grenser, og bruk filer som CLAUDE.md eller AGENTS.md til å peke agenten på hvor ting hører hjemme i kodebasen. Det sparer tokens hver gang en agent skal utforske, fordi den slipper å skanne seg fram til kontekst som kunne vært gjort eksplisitt fra start. Bonusen er at den samme jobben løfter din egen utviklingshastighet: når du rigger kodebasen for agenten, rigger du den samtidig for deg selv.
Her ender jeg opp når jeg forsøker å se 12 måneder fram i tid.
Før agentisk AI var den bindende begrensningen for de fleste typer kunnskapsarbeid menneskelig oppmerksomhet. En ingeniør kunne veie X implementasjonsalternativer per uke, en PM kunne stresse-teste Y posisjoneringsvinkler per kvartal, en CFO kunne kjøre Z finansielle scenarier før et styremøte. På mange måter var taket timer per hode.
Tokens flytter taket fra arbeidsbegrensning til kapitalbegrensning, i hvert fall i langt større grad enn for noen få år siden. Spørsmålet blir: Hvor mange parallelle hypoteser har du råd til å kjøre? Hvor mange design utforsket, arkitekturvalg modellert, finansielle scenarier stresstestet, alternative kodeimplementasjoner undersøkt før lansering til produksjon?
Forskningen bekrefter retningen, men med forbehold. DORA-rapporten for 2025 finner en positiv sammenheng mellom AI-adopsjon og software delivery throughput, og over 80 prosent av utviklere rapporterer økt produktivitet. Men gevinstene er ujevnt fordelt: Stanford-forskning viser 35–40 prosent produktivitetsgevinst på greenfield-oppgaver mot under 10 prosent på kompleks legacy-kode. DORAs viktigste funn er at AI ikke fikser et team, den forsterker det som allerede er der. Sterke team blir sterkere, svake team får svakhetene sine forstørret. Løs kobling i arkitekturen og raske tilbakemeldingsløkker er det som gjør forskjellen. Token-disiplinen er altså ikke en automatisk vei til høyere gjennomstrømming, men heller en spak man kan trekke i dersom man først har gjort grunnarbeidet.
Jeg mener det er viktig å ikke se på tokens som en kostnadslinje. Tokens er en innsatsfaktor, altså en ressurs som direkte inngår i det du som bedrift produserer. En kostnadslinje kan ofte være noe du prøver å minimere, mens en innsatsfaktor er noe du optimaliserer for. En fabrikk prøver ikke å bruke minst mulig strøm; den optimaliserer for å bruke akkurat den strømmen som trengs for å produsere mest mulig til lavest mulig kostnad per enhet. Tokens fungerer på samme måte: spørsmålet er ikke hvor lite du kan bruke mens du jobber, men hvor mye du får ut i andre enden av det du bruker.
Den relevante KPI-en er altså ikke "kroner brukt på tokens", men beslutningskapasitet per token: hvor mange velinformerte valg du klarer å produsere per krone forbrukt i inferens.
Token-økonomien er et større tema enn ett blogginnlegg, og det blir bare større etter hvert som forbruket vokser. Jeg har her bevisst snevret meg inn på det utviklere selv kan gjøre i sin daglige arbeidsflyt. Det betyr at en rekke spørsmål som hører hjemme på ledelsens, plattformteamets og CFO-ens bord, ikke er behandlet her. Noen av de viktigste, slik jeg ser dem:
Utviklingen i token-kostnad denne våren har avdekket en reell sårbarhet. Hele bransjen har bygd arbeidsprosesser oppå en pris som for mange ikke oppleves som økonomisk bærekraftig, og når regningen kommer føles plutselig hele oppsettet skjørt. Å sitte uten toppmodellene i en time føles for mange utviklere som regressivt på en måte som er ny for en utviklerprofesjon vant til at verktøyene bare ligger der til enhver tid.
Men det er noe å hente i dette også. Når tokenene koster det de koster, blir disiplinen rundt modellvalg, kontekst og automatiserte kvalitetssjekker enda viktigere å være bevisst på. Det er nettopp den jobben Salnikov peker på, og det er der verktøy som rtk og caveman gir deg konkrete grep.
Flere og flere bedrifter legger nå merke til at første dose er gratis. Resten betaler vi for. Spørsmålet blir da om vi bruker dem godt.
Sannsynligheten er stor for at du legger merke til dette i løpet av sommeren 2026. Når regnestykket først lander på arbeidsgiverens bord, vil den naturlige refleksen være å snakke om kostnad. Det er den enkleste og mest umiddelbare rammen å ta inn over seg.
Det er der utvikleren har en jobb å gjøre, før samtalen settes i gang av noen andre. Den som flagger dette tidlig, får være med å forme rammen. Jeg mener den rammen bør være basert på verdi per token, ikke et generelt sparepåbud. Domino-dynamikken og horisont-poenget vi så tidligere i innlegget viser hvorfor det betyr noe: et sparepåbud forsterker feilraten gjennom hele flyten, ikke motsatt, og det er nettopp det organisasjonen må unngå.
Magnus bygger AI i Capra, nå på Gjensidiges «Hei, huset!». Han er opptatt av AI som fungerer i praksis og av å rigge tverrfaglige team for en AI-first arbeidsform. Det skriver han om og holder foredrag om.
