AI Credits i GitHub Copilot: kostnadskontroll i praksis

Lenge var GitHub Copilot enkelt å budsjettere: en fast avgift per utvikler og måned. I løpet av 2026 endret det seg. Brukerlisensen finnes fortsatt, men den ble supplert med en kredittbasert fakturering, og det er den endringen som kan gjøre en forutsigbar post til en ubehagelig overraskelse.

Prinsippskiftet: fra fast avgift til forbruk

Den gamle modellen var en flat lisens. Den nye legger en forbruksdel på toppen: kreditter som brukes opp når verktøyet jobber. Poenget med skiftet er at ulike måter å bruke Copilot på koster svært ulikt.

Vanlig kodefullføring, altså forslagene som dukker opp mens du skriver, bruker lite. Tunge agentflyter, der verktøyet får et mål og selvstendig jobber seg gjennom flere steg med en premiummodell, bruker kreditter mange ganger raskere. Samme lisens, helt ulike regninger avhengig av hvordan teamet faktisk jobber.

Hvor ille kan det bli?

Underlaget dokumenterer rapporterte månedsfakturaer som er blitt mangedoblet. Enkelttilfeller er beskrevet med 25 og 60 ganger det forventede nivået, og en bredere erfaring fra brukermiljøet ligger et sted rundt 6 til 27 ganger. Samtidig har brukere som stort sett holder seg til kodefullføring, knapt merket noen forskjell.

Spennet er selve poenget: Det er ikke alle som rammes, men de som kjører mye agentarbeid med de dyreste modellene. Uten tak er det ofte noen få utviklere eller et par automatiserte arbeidsflyter som står for mesteparten av kostnaden.

Slik kan det oppstå i praksis. En utvikler ber en agentflyt om å refaktorere en større del av kodebasen med en premiummodell. Agenten jobber seg gjennom filene i mange steg, leser, prøver, retter og leser igjen, og hver runde bruker kreditter. Det som føltes som én instruksjon, ble i realiteten hundrevis av modellkall. Gang det med noen entusiastiske utviklere i løpet av en måned, så forstår man hvordan en faktura havner langt over den faste lisensen uten at noen har gjort noe åpenbart galt.

De tre virkemidlene

Du trenger ikke å gjette deg frem. Kostnaden kan holdes i sjakk med tre innstillinger:

1. Kredittak per bruker. Sett en grense i policyen slik at ikke noe enkeltforbruk kan komme ut av kontroll. Taket blir en tidlig alarm heller enn en sperre som merkes først på fakturaen.
2. Modellsperre for premiummodeller. Ikke alle team trenger de dyreste modellene. Sperr dem der de ikke tilfører noe, så bruker arbeidsflytene billigere kreditter.
3. CLI av på organisasjonsnivå. Arbeidsflyter fra kommandolinjen kan bruke kreditter i det skjulte. Å slå av CLI på organisasjonsnivå fjerner en hel kategori uovervåket forbruk.

Hvem trenger egentlig premiummodellene?

Nøkkelen til å sette takene riktig er å skille mellom hvordan ulike roller bruker verktøyet. En utvikler som stort sett tar imot forslag til kodefullføring i editoren, bruker lite og trenger sjelden de dyreste modellene. Et team som bygger og kjører agentflyter, som automatisert refaktorering og kodegenerering i stor skala, er der kostnaden oppstår, og der premiummodeller kan være forsvarlige hvis de faktisk tilfører verdi.

Beslutningskriteriet er altså ikke «premium til alle» eller «premium til ingen», men å koble tilgangen til behovet. Gi de tunge agentbrukerne tilgang med et bevisst tak, og hold de andre på de billigere modellene, der de uansett ikke merker forskjell. Taknivået setter dere enklest ved å anslå et realistisk månedsbehov per rolle og legge taket med margin over: høyt nok til ikke å hindre arbeidet, lavt nok til å fange opp et løpsk forbruk tidlig.

En vanlig felle er å rulle ut bredt med premium slått på for alle «for sikkerhets skyld». Da er det nettopp de uovervåkede agentflytene som står for regningen, og ingen oppdager det før fakturaen kommer. Det er bedre å begynne stramt og heve taket for dem som viser et reelt behov.

Ekstra påslag: EU-residens

Aktiverer dere EU-residens av personvernhensyn, kommer det ifølge underlaget et påslag for inferens på kredittene. Det er i seg selv ofte et fornuftig valg for å holde data innenfor EU, men effekten på kredittkostnaden skal regnes inn i budsjettet fra start. Ellers blir compliance-beslutningen en skjult kostnadsdriver.

Regn på det før, ikke etter

Kredittpriser, inkluderte volumer og kampanjekreditter endres over tid, så et tall vi skrev her, ville være utdatert i morgen. Det viktige er rekkefølgen: Regn på deres eget forventede forbruk mot prislisten som gjelder når dere ruller ut, sett takene før utrullingen og følg opp løpende. Sjokket kommer alltid av at taket ble satt etter den første fakturaen i stedet for før.

Vil dere ha hjelp til å modellere forbruket eller sette opp en styringsmodell for AI-verktøy, kan dere lese mer om AI-tjenestene våre eller kontakte oss med en beskrivelse av hvordan teamet jobber i dag.