Hopp til hovedinnhold
 AI-nyheter, ferdig filtrert for ledere
SISTE:

AI-agentpakker på npm ble kapret i 27 minutter • Beijing tvinger Meta til å reversere Manus-kjøp • Amazon-varsel forklarer Anthropic-sperren • Google kan holdes ansvarlig for AI-svar i søk • OpenAI møter ny gransking fra delstatsadvokater

GitHub gjør Copilot-forbruk målbart per bruker
CIOCFOCTOCISOStyreGitHubGitHub CopilotAI FinOpsUsage MetricsKoststyringDeveloper ToolsAI GovernanceProduktivitetInternkontrollLeverandørstyringEnterprise AISoftware Engineering

GitHub gjør Copilot-forbruk målbart per bruker

JH
Joachim Høgby
21. juni 202621. juni 20264 min lesingKilde: GitHub Blog

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.