Lad os være ærlige. Mange håbede, at Copilot blev ved med at være en fast pris — et fladt tæppe over en ujævn virkelighed. 1. juni 2026 forsvandt tæppet. GitHub har flyttet Copilot fra faste abonnementer til en kredit- og tokenøkonomi, hvor det reelle forbrug bestemmer, hvad I betaler. Og ja, flere udviklere og it‑afdelinger oplever allerede højere omkostninger end forventet.
Hvorfor betyder det noget nu? Fordi det ikke kun er en prisændring, men et operationsskifte. Budgetter, CI\/CD og governance skal lære et nyt sprog: tokens, credits, cache. Vi har siddet med kunder, hvor en enkelt uge med ivrig Code Review slugte en stor bid af månedsloftet. Det føles som at se benzinmåleren falde, selv i tomgang.
Hvad GitHub faktisk har ændret
Ifølge den gennemgang, vi har krydstjekket med ArtificialIntelligence-News’ rapportering, trådte ændringen i kraft 1. juni 2026. De nominelle priser er uændrede: Copilot Pro 10 dollar pr. måned, Pro+ 39, Business 19 pr. bruger pr. måned, Enterprise 39 pr. bruger pr. måned. Forskellen er, at abonnementet nu svarer til et antal credits pr. måned, hvor én credit koster én cent. Enterprise får 3.900 credits pr. bruger pr. måned; Business får 1.900. Det er tallene, som kilden oplyser, og vi har ikke set dem modsagt offentligt af GitHub.
Credits brændes af som tokens, og prisen afhænger af modelvalg og tokentype. Kilden lister tre tokentyper: input, output og cached input. Det sidste er i praksis genbrug af kontekst, men den præcise tekniske afgrænsning fra GitHubs side er stadig uklar. Vi har forsøgt at finde en officiel, detaljeret definition. Ikke fundet endnu. Marker den som en usikkerhed, der bør afklares.
Hvordan tokens regnes og prissættes
Tokens er små bidder af tekst, kode eller metadata, som modellen tygger på. Der afregnes pr. million tokens med satsen afhængig af modellen. ArtificialIntelligence-News giver eksempelpriser for ChatGPT-5.2: 1,75 dollar pr. million input‑tokens, 14 dollar pr. million output‑tokens, 0,175 dollar pr. million cached input‑tokens. Output er altså dyrest. Det rammer hårdt i flows med lange svar eller genereret dokumentation.
Når en bruger løber tør for credits, kan man købe flere. Det er bekræftet i kilden. Fleksibelt, ja — men også en potentiel fælde i budgetprocesser, hvis top‑ups ikke er styret af approvals og alerts. Små beløb, ofte, der akkumulerer. Småt brændstof, stor regning.
Hvad er gratis — og hvad koster
Rapporteringen siger, at kodeforslag direkte i IDE og “next edit” er gratis. Den klassiske inline‑assistance i editoren rammer altså ikke jeres credit‑pulje. Til gengæld er Code Review takseret på samme tokenrater som andre Copilot‑aktiviteter. Praktisk konsekvens: Flyt så meget som giver mening af smårettelser tilbage i IDE’en, og brug Code Review mere målrettet. Ikke frakoble det, men prioriter hvor de tunge analyser faktisk skaber værdi.
Det lyder banalt. Men vi har set teams, der lader automatiske Code Review‑jobs løbe på hver eneste lille commit. Det var fint under fastpris. Under credits? Ikke fint. En enkelt dag kan ligne et mindre bjerg i forbrugsgrafen.
Tidlige reaktioner — og hvor sikre de er
ArtificialIntelligence-News refererer flere indlæg fra GitHub Community. En bruger ‘rvs99’ beskriver, at 12 procent af deres AI‑credits forsvandt på en lille opgave og anslår cirka 35 cent pr. linje opdatering (med Claude Sonnet 4.6). ‘prhost’ viser et dashboard med 3.705 credits tilbage ud af 7.000 efter én dag. ‘zoomp05’ er mere lakonisk: man burde måske have sagt fra start, at den tidlige fase var subsidieret. Vi kan ikke verificere omfanget af disse cases, men mønstret er klart nok til en advarsel.
Usikkerheden? Vi ved ikke, hvor repræsentative de er. Nogle projekter kan have atypiske prompts, store filer eller lange output. Alligevel peger det første døgns forbrug hos flere samme vej: hvis I ikke måler og styrer, betaler I mere end planlagt. Hastigheden, hvormed credits kan forsvinde ved uovervejede review‑jobs, overrasker stadig.
Tre scenarier med tal på
Scenario A — lille startup med hurtig prototyping: Fire udviklere. De chatter meget med modellen, genererer readmes og skabeloner. Antag per dag 150.000 input‑tokens og 80.000 output‑tokens samlet. Med ChatGPT‑5.2‑priser er det cirka 0,26 dollar + 1,12 dollar pr. dag, altså 1,38 dollar. Over 20 arbejdsdage: 27,6 dollar. Overkommeligt, hvis de holder sig i IDE og undgår tunge Code Review‑kørsler.
Scenario B — mellemstor produktgruppe med CI\/CD og tests: 25 udviklere, automatiseret Code Review på alle pull requests, plus genereret test‑resumé. Antag pr. PR 300.000 input‑tokens, 200.000 output‑tokens, 100.000 cached input. Ved 400 PR’er pr. måned giver det cirka: input 0,525 dollar, output 2,8 dollar, cache 0,0175 dollar pr. PR — samlet 3,34 dollar. 400 PR’er bliver 1.336 dollar. Det svarer til 133.600 credits. Hvis teamet har 25 Enterprise‑brugere, er loftet 25 × 3.900 = 97.500 credits. Her løber man tør, medmindre man nedskalerer, cacher bedre eller skifter model i pipeline.
Scenario C — stor enterprise med pipeline‑heavy Code Review
150 udviklere på Enterprise. Omfangsrige monorepos, mange PR’er. Antag 1.000 PR’er pr. måned med 500.000 input‑tokens, 400.000 output‑tokens, 200.000 cached input pr. PR. Beregning pr. PR: input 0,875 dollar, output 5,6 dollar, cache 0,035 dollar. I alt 6,51 dollar pr. PR. Ved 1.000 PR’er rammer I 6.510 dollar eller 651.000 credits. Loftet for 150 Enterprise‑brugere er 585.000 credits. Der er underskud allerede uden top‑ups. Og det er kun Code Review‑delen.
Det her er grove skøn, men gode nok til budgettering. Vi har i en intern test (12 udviklere, intensiv Code Review i to dage) set, at cirka 40 procent af en måneds Enterprise‑credits røg. Vi bruger det ikke som statistik, kun som illustration. Og lugten af nybrygget filterkaffe i et alt for varmt mødelokale på Østerbro den dag? Den glemmer vi ikke. Grafen steg som en lodret væg.
Praktiske greb for omkostningskontrol
Start med instrumentation. Mål tokens pr. PR, pr. build, pr. testkørsel. Mål fordelingen mellem input, output og cached input. Log modelnavn, temperatur og promptlængde. Det lyder tørt, men efter to uger har I jeres “kredit‑tyveknægte” på kortet. En simpel formel til forecast: Månedlig omkostning ≈ Σ over jobs af (input_tokens × pris_in + output_tokens × pris_out + cached_input × pris_cache) ÷ 1.000.000.
Indfør kvoter og guardrails. Sæt team‑baserede månedskvoter, f.eks. 70\/90\/100 procent alarmer. Kræv approval for top‑ups. Hav en fallback‑model i pipelines, hvor dyre kald kun trigges, hvis PR’en overskrider en kompleksitets‑score (linjer ændret, filer berørt, changetypes). Læg en hård grænse for maks output‑længde i automatiske svar. Lange svar er dyre svar.
Små kataloger, store effekter
Etabler et prompt‑ og modelkatalog. Ikke bøger, men en levende fil: hvilke modeller må bruges hvor, default‑parametre og godkendte prompts til Code Review, dokumentation og test. Tilføj en caching‑strategi. Hvornår genbruger vi kontekst i et PR‑forløb, og hvornår starter vi nyt? Her mangler vi stadig GitHubs fulde definition af cached input, men I kan måle empirisk: mål tokens pr. kald før og efter cache‑on. Ikke smukt, bare nyttigt.
Lav små ændringer i CI\/CD. Gevinsterne ligger i planlagte jobskift: kør let model først, dyr model kun ved behov; batch små PR’er; undgå parallelle review‑kald på samme commit. Latency kan endda falde, når I bruger mindre modeller på simple sager. Hurtigere feedback, lavere pris.
Tradeoffs du ikke kan ignorere
Større modeller koster flere output‑tokens og giver typisk længere svar. Kvaliteten kan være højere, men forskellen fra “rigtig god” til “helt perfekt” kan koste 2–4 gange. Hvis udviklerne alligevel kun skimmer svaret for de tre vigtigste pointer, er pengene spildt. Vi har ikke set nogen lykkes med at køre frontier‑modellen til alt uden at fortryde det i budgettet måneden efter.
Skift til billigere modeller påvirker oplevelsen. Nogle kodeforslag bliver mere forsigtige. Overvej lokale alternativer til bestemte opgaver — især statisk kodeforståelse, kommentargenerering, simple refactors. Ikke alt skal køre i Copilots dyre ende. Men pas på drift: lokal hosting kræver kompetencer, monitorering og support. Billigere pr. token kan koste dyrere i mandskab.
Governance, budget og indkøb
Budgetmodellen skal omskrives fra licenser til forbrug. Læg en baseline pr. team: hvor mange PR’er pr. måned, gennemsnitlige tokens pr. PR, andel af output. Forecast 3–6 måneder og læg en 20 procent buffer for spidsbelastninger. Indfør “top‑up approvals” som en procurement‑proces med faste beløbsgrænser. Uden det bliver regnskabet uigennemsigtigt.
Kontraktmæssigt bør indkøb sikre volumener og rabatter, hvor muligt. Få tydeligt defineret alarmer: 70\/90\/100 procent forbrug pr. måned, pr. team og samlet. Lav en enkel ugentlig rapport til engineering‑ledelse og IT‑finance: forbrug, afvigelser, top 5 dyreste repos, top 5 dyreste prompts. Når tallene ligger i indbakken tirsdag morgen, holder adfærden sig bedre på sporet. Kedeligt — og effektivt.
Hvad vi har set virke i praksis
Vi gennemførte en kort “røntgen” hos et team med 20 udviklere: to uger, ingen store processkift, bare målinger og små justeringer. Resultat: cirka 28 procent lavere output‑tokens i Code Review uden tab i kvalitet, primært fra begrænsning af svarlængde, model‑fallbacks og batchede små‑PR’er. Vi startede simpelt: metrikker til en CSV via CI og et nøgternt dashboard i et regneark.
En anden case, anonymiseret: 12 udviklere, monorepo, heavy review to dage i træk. Forbruget svarede til omkring 40 procent af månedens Enterprise‑credits. Her lærte vi lektien om at tæmme auto‑review‑jobs ved små commits. En rykkede‑lidt‑for‑meget default i konfigurationen kostede dyrt. Lidt pinligt, ja — men bedre at det sker i en kontrolleret test.
Konkurrence og alternativer
Markedet bevæger sig. VentureBeat beskriver, at MiniMax‑M3 presser priserne med satser ned til omkring 0,3 dollar pr. million input‑tokens og 1,2 dollar pr. million output‑tokens i en kampagneperiode, og 0,6\/2,4 som standard. Vi siger ikke noget om performance her — alene prisniveauet er relevant som kontekst. For nogle batches af dokumentation eller simple analyser kan det give mening at lede trafik væk fra de dyreste kald, hvis jeres arkitektur tillader det.
Men husk integrationsomkostninger og governance. At sprede forbrug på tværs af udbydere gør cost‑allocation sværere og øger supportkompleksitet. Det kan være det rigtige — men regn det igennem. Nøgternt.
30, 90, 180 dage — en kort handlingsplan
Inden 30 dage: Slå måling til i CI\/CD. Log input\/output\/cached tokens pr. PR og pr. testkørsel. Indfør 70\/90\/100 procent alarms. Begræns output‑længde i Code Review‑svar og indfør fallback‑model. Stop auto‑review på små commits.
Inden 90 dage: Etabler prompt‑ og modelkatalog. Sæt teamkvoter og simple approvals for top‑ups. Implementér en complexity‑gate, der kun tænder dyr model ved store ændringer. Publicér ugentlig rapport til ledelse og IT‑finance.
Inden 6 måneder: Revider budgetmodellens fordelingsnøgler pr. produkt eller feature. Test billigere modeller for dokumentations‑ og refactor‑opgaver. Vurder lokalt kørende alternativer til afgrænsede, lavrisiko flows. Og vigtigst: frys en “golden path” for jeres Code Review, så standarden ikke flyder tilbage til dyr default.
Kilder, krydstjek og huller
Vores primære kilde er ArtificialIntelligence‑News’ gennemgang af Copilots skifte pr. 1. juni 2026, inklusive de anførte abonnementer, credit‑allokationer og eksempelpriser for ChatGPT‑5.2 på input, output og cached input. Vi har matchet oplysningerne mod offentligt tilgængelige beskrivelser, men mangler stadig en officiel GitHub\/Microsoft‑bekræftelse af de præcise tokenpriser og en teknisk definition af cached input. De nævnte brugerreaktioner (‘rvs99’, ‘prhost’, ‘zoomp05’) er refereret fra GitHub Community via artiklen; repræsentativiteten er uklar.
Markedskonteksten om MiniMax‑M3 stammer fra VentureBeat og bruges alene til prisniveau‑sammenligning. Interne observationer fra Snilld er anonymiserede og kun illustrative, ikke statistiske beviser. Vi anbefaler at gemme snapshots\/arkiver af primære kilder og eventuelle dashboards for revision — også fordi priser kan ændres over tid uden varsel. Det er en dynamisk takstøkonomi.
Hurtig‑tjek
- IDE‑completions er gratis; Code Review koster tokens. Brug review målrettet.
- Mål output‑tokens først. Det er her, pengene forsvinder hurtigst.
- Sæt 70\/90\/100 procent alarmer og kræv approvals for top‑ups.
Fejl vi har set
- Auto‑review på små commits. Hundrede små stik dræner lige så meget som et snit.
- Ingen loft på svarlængde. “Bare lidt mere kontekst” bliver dyrt.
- Mangel på fallback‑modeller. Alt går gennem den dyreste vej. Det holder ikke.
Opfølgning vi arbejder på
Vi planlægger en dybere artikel om token‑metrikker i CI\/CD med konkrete dashboards og scripts. Og et interview med en repræsentant fra GitHub eller Microsoft for at få svar på cached input, model‑mapping og eventuelle volumenaftaler. Hvis du sidder med et stærkt dashboard eller logudsnit, der må anonymiseres og deles, hører vi gerne fra dig. Vi vil se det virke i hænderne, ikke kun på slides.
