De skjulte kostnadene ved AI i stor skala

Den 1. juni 2026, GitHub avskaffet permanent flat-rate \”premium requests\” for Copilot og erstattet dem med bruksbaserte AI‑kreditter. Da de første fakturaene under den nye modellen kom en måned senere, så noen agentbaserte brukere regninger de ikke var forberedt på: En utvikler rapporterte at de månedlige kostnadene hoppet fra $29 til $750 for de mest krevende agentbaserte arbeidsflytene.

Det var et synlig eksempel på en bredere endring i AI‑verktøymarkedet gjennom 2026 – og en som kan vente på organisasjoner som fortsatt betaler en flat pris i dag.

Organisasjoner teller timene de sparer. Mange av dem teller ikke det en flat pris holder skjult: kontekstforbruk og gjentatte forsøk etter feil. Andre kostnader vises aldri på leverandørens faktura, inkludert tiden som brukes på å gjennomgå output og vedlikeholde prompts. Når faktureringen skifter til faktisk forbruk, risikerer organisasjoner uten kostnadsdisciplin en regning som overrasker dem på samme måte som Copilots nye modell overrasket noen brukere.

Konteksten ingen har priset inn

AI trenger åpenbart kontekst; det er ikke til tvil. Spørsmålet er om den sendte konteksten er relevant, eller bare praktisk tilgjengelig. Å sende et helt dokument er den raskeste måten å gi en modell informasjon på. Det er ikke automatisk den billigste eller den beste måten.

I mai 2026 publiserte Stanford’s Digital Economy Lab en analyse av agentbaserte kodeoppgaver på tvers av åtte frontier-modeller og fant at disse oppgavene forbruker opptil tusen ganger flere token enn en enkel kode‑chat, med hovedårsaken ikke modellens output, men inn‑konteksten den sender på nytt gang på gang. Agenten leser hele historikken sin på nytt ved hvert påfølgende steg. Den samme oppgaven, kjørt flere ganger, varierte i token‑forbruk opptil tretti ganger.

Nøyaktigheten skalerer heller ikke lineært med mengden kontekst: den topper ofte ved en moderat mengde og legger deretter bare til kostnad uten å tilføre verdi.

Token‑blindhet handler derfor ikke om at AI ikke trenger kontekst. Det handler om at uten måling stiller ingen spørsmålet om all den konteksten faktisk er nødvendig. Under en flat pris er spørsmålet lett å ignorere. Under forbruksbasert fakturering blir det en del av kostnaden.

Når du betaler for feil to ganger

Agentbaserte arbeidsflyter medfører en annen kostnad som nesten aldri vises i ROI‑beregninger. Forestill deg en forenklet kjede med ti steg, hver med 95 prosent sjanse, for seg selv, til å kjøre korrekt. Det høres pålitelig nok ut, men når de settes sammen, har den kjeden bare omtrent 60 prosent sjanse til å fullføre hele kjøringen uten en eneste feil.

I en arbeidsflyt som sender den akkumulerte konteksten på nytt ved hver kall, koster hver feil og påfølgende gjentakelse deg ikke bare det gjentatte steget: du betaler også igjen for alt som ble sendt før den.

Det er en vanlig smerte de fleste opplever når de bygger sin første agentbaserte pipeline. Jeg gikk gjennom det selv. Tidlig, med bare noen få agenter, betydde det ikke så mye. Men etter hvert som pipelinen vokste, ble hver mislykkede kjøring dyrere, og det var det som fikk meg til å begynne å spørre hvilken kontekst hver agent trengte og hvordan den kunne caches, i stedet for bare om kjøringen gikk gjennom.

Den samme analysen beregner at en ti‑stegs agent med 95 prosent pålitelighet per steg bruker omtrent 40 prosent flere token på gjentakelser enn et helt pålitelig system. Dette er en kostnad du vil se på fakturaen, men som sannsynligvis ikke vil bli funnet i noe ROI‑regneark.

Tilsyn er ikke en feil. Det hører hjemme i budsjettet.

Dette poenget må formuleres presist, fordi det er lett å ta feil. Å gjennomgå AI‑output er ikke en systemfeil; det er en legitim, forventet del av å jobbe med AI, på samme måte som kodegjennomgang er en legitim del av å jobbe med utviklere. Problemet er ikke at output blir gjennomgått. Problemet er at dette arbeidet nesten aldri tas med i beregningen av hvor mye AI faktisk har spart.

Glean’s Work AI Institute undersøkte 6 000 arbeidere og fant at automatisering sparer dem omtrent 11 timer per uke, men nesten seks og en halv av de timene går til vedlikeholdsoppgaver: å gi AI‑systemer kontekst, sjekke arbeidet deres og rydde opp feil. Netto‑besparelsen er da nærmere fire og en halv time – mindre enn halvparten av hovedtallet. AI sparer fortsatt tid, bare ikke så mye som det første tallet antyder.

Prompter trenger vedlikehold, ikke bare en forfatter

Prompter oppfører seg i dag mer som produksjonskode: en modelloppdatering, en endring i kontekst eller tilsynelatende mindre redigering kan endre hvordan de fungerer. Uten versjonering og testing kan disse endringene stille introdusere problemer. Regresjonstester som er standardpraksis for kode blir fortsatt ofte hoppet over når det gjelder verifisering av prompter. En endring som ser ut som en mindre redigering av en enkelt setning kan nå produksjon og redusere nøyaktigheten uten at noen merker det før problemet har akkumulert seg til noe synlig.

Å bygge et riktig evalueringsrammeverk – inkludert et testsett og automatiserte regresjonstester på hver endring – er ekstra arbeid som nesten aldri vises i beregningen \”AI sparer tid\”.

Billigere token, høyere regninger

GitHub Copilot var ikke et unntak. En undersøkelse sitert av CFO Dive fant at nesten syv av ti amerikanske selskaper rapporterte minst delvise AI-budsjettoverskridelser det siste året, mest før en full overgang til forbruksbasert fakturering, ikke etter den.

Bain & Company, i sin juni-analyse av tokenøkonomi, legger til et paradoks som fanger hele situasjonen best: prisen per token falt med halvparten i løpet av året, mens forbruket i samme periode vokste 4,5 ganger.

Modellen ble billigere, men regningen forblir sta høy. Selskaper gikk over til nyere modeller, ga agenter mer komplekse oppgaver og fant flere arbeidsflyter for dem. En billigere token betydde ikke lavere forbruk; det betydde at det var flere grunner til å bruke en.

Hvordan forberede seg før regningen kommer

Rammen som følger av dette handler ikke om å bruke mindre AI. Det handler om å kjenne AI-kostnadene før du bestemmer deg for å skalere den videre.

1. Få oversikt først

Inntil du har forbruket brutt ned på team, arbeidsflyt, applikasjon og fullført oppgave, er hver utvidelse et blindt gamble. Den oversikten er heller ikke gratis: for agentbaserte arbeidsflyter spesielt krever sporing av hvert trinn, logging av hva som skjedde og hvorfor, samt overvåking av løpende løkker sin egen ingeniørtid og verktøy. Budsjetter for dette som en del av kostnaden ved å drive AI, ikke som en ettertanke på toppen av den.

2. Rekalkuler ROI på netto basis

Trekk fra tiden brukt på gjennomgang, rettinger og vedlikehold av prompt fra de rapporterte timene spart. Hvis tidsbesparelse er formålet med brukstilfellet og nettoresultatet er negativt eller uverifiserbart, er det ikke klart for skalering. Hvor den tiltenkte fordelen er kvalitet, kapasitet, risikoreduksjon eller inntekt i stedet, mål dette resultatet direkte.

3. Påfør kostnadsdisiplin, men ikke jevnt

En streng forbruksgrense gir mening der feil er billige: interne verktøy, eksperimentelle agenter, utviklingsmiljøer. For kritisk, kundevendt funksjonalitet – for eksempel en kundeserviceassistent – er en streng grense ikke gjennomførbar, fordi den skaper risiko for driftsstans. Der trenger du lagdelte tilbakefall til en billigere modell og tidlige varsler, ikke en avstengning ved null.

4. Behandle prompts og evalueringsverktøy som ingeniøremidler

Versjonér dem, test dem og gjennomgå endringer før utrulling, på samme måte som du ville håndtert produksjonskode.

Gå inn i fornyelser med dine egne data

Leverandørpriser er vanskelige å evaluere uten dine egne bruksdata. Før en fornyelse eller modellendring, beregn hva dine eksisterende arbeidsflyter ville kostet under de foreslåtte vilkårene. Målet er ikke bare å forhandle frem en lavere pris. Det er å vite hvordan den prisen vil oppføre seg på ditt faktiske forbruksnivå, i stedet for å finne det ut fra fakturaen.

Tre ting du kan gjøre denne uken: sjekk om du kan bryte ned AI-forbruket etter team og arbeidsflyt; velg ett brukstilfelle og sett tiden brukt på gjennomgang ved siden av timene som er rapportert spart; og finn ut hvor en streng forbruksgrense kan skape en driftsstans i stedet for å kontrollere en kostnad.

AI-kostnader kan håndteres. Bare ikke når du får vite hva de er for første gang fra regningen.