GitHub gjør Copilot-forbruk målbart per bruker
GitHub gjør Copilot-forbruk enklere å måle på brukernivå. I Copilot usage metrics API ligger det nå et nytt felt, ai_credits_used, som viser hvor mange AI-credits hver bruker har brukt per dag. Feltet finnes i user-level-rapportene for én dag og 28 dager, både på enterprise- og organisasjonsnivå.
For store virksomheter er dette mer enn en liten API-endring. Det er nok et tegn på at AI-assistenter flytter seg fra entusiasmebudsjett til ordinær økonomistyring.
GitHub skriver at dataene er hentet fra samme forbruksgrunnlag som usage-based billing API. Samtidig presiserer selskapet at feltet er et metrikksignal, ikke en fakturalinje. Det brytes heller ikke ned på funksjon, modell eller flate. En leder kan altså se total Copilot-bruk per bruker, men ikke nøyaktig om forbruket kom fra chat, kodefullføring, review eller agentfunksjoner.
Det er likevel nok til å endre styringsdialogen.
Fra lisens til forbruk
Første generasjon Copilot-styring handlet mest om seter. Hvor mange hadde tilgang, og hvor mange brukte verktøyet? Nå blir spørsmålet mer presist: Hvem bruker mye, hvor varierer forbruket, hvilke team driver veksten, og hvordan henger dette sammen med leveranser?
For CIO og CFO er det nyttig. AI-kostnader er i ferd med å ligne cloud-kostnader. Små enheter tar i bruk verktøy raskt, bruken sprer seg, og noen måneder senere dukker regningen opp som en kombinasjon av abonnement, credits, modellvalg og agentkjøringer. Uten måledata blir diskusjonen fort ideologisk. Med måledata kan den bli operativ.
Det betyr ikke at ai_credits_used automatisk viser verdi. Høyt forbruk kan være produktivt arbeid. Det kan også være dårlig prompt-hygiene, overbruk, eksperimentering uten retning eller agentløp som burde vært stoppet av en policy. Lavt forbruk kan bety at teamet jobber effektivt uten Copilot. Det kan også bety at lisensen er bortkastet.
Tallene må kobles til kontekst.
Hva ledere bør bruke dataene til
Det første bruksområdet er budsjett. Enterprise-admins kan se forbruksmønstre dag for dag og planlegge for usage-based billing. Det gjør det lettere å sette interne rammer, varsler og showback-modeller før kostnaden blir et irritasjonsmoment.
Det andre er adopsjon. Hvis ett utviklerteam bruker Copilot tungt og leverer raskere med god kvalitet, bør andre team lære av arbeidsformen. Hvis et annet team har høyt forbruk uten tilsvarende flyt i leveransene, bør man se på prosess, review, testdekning og oppgaveutforming.
Det tredje er leverandørstyring. Copilot er ikke lenger bare et utviklerverktøy. Det er en løpende AI-plattform i engineering. Når forbruket kan måles per bruker, kan virksomheten stille bedre spørsmål til GitHub, til interne plattformeam og til sikkerhetsfunksjonen: hvilke data sendes, hvilke modeller brukes, hvilke policyer gjelder, og hva skjer når agenter får mer autonomi?
Det fjerde er internkontroll. AI-verktøy som skaper kode, foreslår endringer og etter hvert kan gjøre mer agentisk arbeid, bør ikke styres bare gjennom innkjøp. Bruksdata må inn i samme rytme som sikkerhetsmålinger, kostrapporter og engineering-metrikker.
Fallgruven: individuell overvåking
Det er også en tydelig risiko. Per-bruker-data kan misbrukes som en enkel produktivitetsmåling. Det bør ledelsen unngå.
AI-credit-forbruk sier lite alene. En seniorutvikler kan bruke få credits fordi vedkommende løser vanskelige problemer manuelt. En junior kan bruke mye fordi verktøyet fungerer som sparring og læring. En kodeagent kan bruke mye fordi oppgaven er stor, eller fordi den går i sirkler. Hvis tallet brukes som pisk, får virksomheten dårligere adferd og dårligere data.
Bruk målingen til kost, mønstre og forbedring. Ikke til å rangere ansatte på en dashboard-skjerm.
Den strategiske retningen
GitHub følger samme retning som resten av enterprise-AI-markedet: mer synlighet, mer forbruksstyring og tettere kobling mellom bruk og kost. OpenAI, Microsoft, AWS og andre går samme vei. Det er nødvendig. Uten tall blir AI enten dyrt leketøy eller ukontrollert infrastruktur.
For norske virksomheter er anbefalingen enkel. Etabler AI FinOps før kostnaden blir et problem. Start med de verktøyene som allerede er bredt rullet ut, som Copilot. Definer hvem som eier forbruket, hvem som vurderer verdi, hvilke terskler som utløser oppfølging, og hvordan måledata skal brukes etisk internt.
Da blir ai_credits_used mer enn et nytt API-felt. Det blir en brikke i et voksenstyrt AI-program.
Kilder og medier
Primærkilde: GitHub Blog, «AI credits consumed per user now in the Copilot usage metrics API»: https://github.blog/changelog/2026-06-19-ai-credits-consumed-per-user-now-in-the-copilot-usage-metrics-api
Kildekreditering: GitHub Blog for beskrivelse av ai_credits_used, API-dekning, begrensninger og bruksområder for Copilot usage metrics.
Thumbnail: OpenAI Image 2 / hogby.ai.
📬 Likte du denne?
AI-nyheter for ledere. Kuratert av en CIO som bygger det selv. Daglig i innboksen.