GitHub Copilot Enterprise: En guide till Spaces och Usage Metrics API

Vad är GitHub Copilot Enterprise?

GitHub Copilot Enterprise ligger högst upp i GitHubs Copilot-planhierarki.

Jämfört med GitHub Copilot Business eller Pro+ fokuserar Enterprise starkt på styrning, organisatoriskt sammanhang och mätmöjligheter. Det är utformat för företag som driver stora ingenjörsmiljöer snarare än enskilda utvecklare eller små team.

Två funktioner spelar störst roll i praktiken:

1. Anpassat organisatoriskt sammanhang via Spaces
2. Telemetri på organisationsnivå via Usage Metrics API

Dessa två funktioner förflyttar Copilot från ”smart autokomplettering” till något som ligger närmare en intern AI-plattform för ingenjörer.

Företag som får ut mest värde av GitHub Copilot Enterprise behandlar det som en nyckelkomponent i den interna infrastrukturen. De konfigurerar organisatoriskt sammanhang noggrant, mäter adoption kontinuerligt och justerar policyer baserat på användningsdata snarare än antaganden.

För en bredare överblick av GitHubs ekosystem rekommenderar jag vår guide Introduction to GitHub Products.

Hur Enterprise skiljer sig från Business och Pro+

GitHub Copilot Enterprise bygger vidare på Business-prenumerationen med ytterligare funktioner som:

• Användningsstatistik på organisationsnivå
• Utökade styrningskontroller
• Policyarv på företagsnivå
• Större tilldelning av premiumförfrågningar (1 000 vs 300 i Business-nivån)
• Ytterligare modellåtkomst och -hantering

Enterprise kräver GitHub Enterprise Cloud utöver själva Copilot Enterprise-prenumerationen. Detta medför en extra kostnad per användare, så se till att din organisation faktiskt behöver styrning, telemetri och administration på företagsnivå.

Obs: Business-prenumeranter har åtkomst till Usage Metrics API på organisationsnivå (/orgs/{org}/…). Enterprise-prenumeranter har dessutom åtkomst till aggregerade rapporter för hela företaget (/enterprises/{enterprise}/…) som täcker alla organisationer i en vy.

Vem GitHub Copilot Enterprise är för

GitHub Copilot Enterprise riktar sig till organisationer som redan driver mogna GitHub-miljöer.

Typiska Enterprise-kunder inkluderar:

• Stora ingenjörsorganisationer
• Reglerade branscher
• Plattformsingenjörsgrupper med flera team
• Företag med interna utvecklingsstandarder
• Organisationer som kräver centraliserad styrning

Observera att detta inte i sig förbättrar Copilots prestanda. Jag tycker att den här skillnaden är viktig eftersom många team initialt överköper. De antar att Enterprise är lika med ”bättre Copilot”, när verkligheten är att Enterprise främst lägger till verktyg för styrning och mätning.

Copilot Spaces: Anpassat sammanhang för din organisation

Copilot Spaces löser en av de största svagheterna hos generella AI-kodassistenter.

Direkt ur lådan förstår Copilot offentlig programmeringskunskap ganska bra. Den förstår inte automatiskt dina interna API:er, arkitekturbeslut, kodningskonventioner, deployflöden eller onboarding-dokumentation.

Spaces tillhandahåller ett kurerat organisatoriskt sammanhang som Copilot kan referera till under konversationer och kodningshjälp.

I praktiken hjälper Spaces Copilot att svara på frågor som:

• ”Hur strukturerar vi API-handlers internt?”
• ”Vilket autentiseringsbibliotek rekommenderar vårt plattformsteam?”
• ”Vilket deployflöde ska den här mikrotjänsten använda?”
• ”Vilka namngivningskonventioner följer vårt backend-team?”

Vad Spaces stöder

Spaces stöder ett bredare spektrum av organisatoriskt innehåll än det äldre systemet Knowledge Bases.

Innehållstyper som stöds inkluderar:

• Kodfiler
• Markdown-dokumentation
• JSON-filer
• Uppladdade filer
• Bilder
• GitHub Issues
• Pull requests

Varje innehållstyp bidrar på olika sätt.

Kodfiler hjälper Copilot att förstå implementationsmönster. Markdown-filer ger arkitekturförklaringar och onboarding-vägledning. Pull requests exponerar granskningsdiskussioner och historiska ingenjörsbeslut. Den kombinationen ger Copilot bättre förståelse för din organisations utvecklingspraxis.

En subtil men viktig poäng är att Spaces inte bara är vektordatabaser kopplade till GitHub. De inkluderar delningskontroller och organisatoriska styrningsflöden utformade för företagsmiljöer.

Knowledge Bases avvecklas

GitHub avvecklade den äldre funktionen Copilot Knowledge Bases den 1 november 2025.

Spaces ersatte Knowledge Bases med:

• Bredare innehållsstöd
• Bättre delningskontroller
• Förbättrad administration
• Mer flexibel hantering på organisationsnivå

Du kommer fortfarande att hitta inaktuell dokumentation och blogginlägg som refererar till Knowledge Bases. Var försiktig när du följer äldre handledningar, eftersom många endpoints och arbetsflöden ändrades under övergångsperioden 2025 till 2026.

Skapa och konfigurera Copilot Spaces

Ur ett administrationsperspektiv är Copilot Spaces ganska enkla att skapa. Utmaningen kommer när man ska hantera dussintals eller hundratals av dem över flera team.

Strukturen du väljer tidigt tenderar att bli kvar. Jag har sett organisationer av misstag skapa ”dokumentationssprawl” i Spaces eftersom ingen fastställde ägarregler från början.

Vem som helst kan skapa ett Copilot Space, så låt oss testa att skapa ett i vårt personliga repo. Stegen är liknande på Enterprise-nivå, med några olika sidor.

Konfigurera ett Space

Att skapa ett Space följer i allmänhet detta arbetsflöde:

1. Navigera till sidan Copilot Spaces i ditt företags administrationsområde
2. Skapa ett nytt Space

3. Välj repos och innehållskällor, inklusive MCP:er och andra användbara verktyg

4. Att lägga till källor kan göras genom att klicka på knappen ”+ Add sources” på höger sida

5. Du kan välja att dela spacen eller ställa in delningsinställningar i detta skede

6. Verifiera att Copilot kan referera till innehållet under chattinteraktioner

En notis för företagsanvändare: din administratör kan stänga av delning av personliga Spaces. Så om du använder ditt eget konto kan det påverka din möjlighet att dela ett Copilot Space som inte använder företagets repos.

Efter konfigurering bör administratörer testa spacen med praktiska uppmaningar.

Till exempel:

How does our authentication middleware handle token refresh logic?

Eller:

Show me an example of how our backend services structure database migrations.

Om Copilot inte kan svara korrekt beror det oftast på:

• Saknade repos
• Dålig dokumentationskvalitet
• Felaktiga behörigheter
• Otillräcklig indextid

Delning och åtkomstkontroller

Spaces stöder två huvudsakliga synlighetsmodeller:

• Individuella Spaces
• Organisationstäckande Spaces

Medlemmar i ett företag kan få sina individuella spaces hanterade av de större företagsinställningarna. Företagsadministratörer kan också centralt hantera policyer för förhandsvisning och funktions­tillgänglighet. 

Privata Spaces fungerar bra för experimentella team eller känsliga interna initiativ. Organisationstäckande Spaces är vettiga för ingenjörsstandarder, onboarding-dokumentation eller företagsövergripande ramverk.

Ett misstag jag ofta ser är övercentralisering. Ett enda, gigantiskt företagsövergripande Space kan bli stökigt och svårt för Copilot att använda effektivt.

Organisera Spaces efter team eller domän

Det finns ingen universellt korrekt organisationsstruktur.

Vanliga mönster inkluderar en space per team, en space per produktområde eller delade standard-spaces. Var och en har ett annat omfång och använder i princip samma inställningsutrymme på olika sätt.

En Space per team

Användbart när ingenjörsgrupper arbetar relativt oberoende.

Exempel:

• Plattformsutveckling
• Data engineering
• Mobilutveckling

En Space per produktområde

Användbart för organisationer som är strukturerade kring produkter snarare än avdelningar.

Exempel:

• Betalningar
• Analys
• Infrastruktur
• Kundplattform

Delad standard-space

Många organisationer upprätthåller en separat delad space för:

• Säkerhetsriktlinjer
• Kodningskonventioner
• Deployflöden
• Arkitekturstandarder

I praktiken fungerar hybridupplägg oftast bäst. Varje team kan få sin egen space, med större standard-spaces som delas mellan teamen.

Copilot Usage Metrics API

Spaces löser kontextproblemet. Usage Metrics API löser mätproblemet. Det ersatte flera äldre telemetrisystem som GitHub avvecklade under API-konsolideringen 2026. 

Utan tydliga mätningar förlorar organisationer snabbt insyn i om Copilot-adoptionen lyckas. Ledningen vill ha bevis på att investeringen förbättrar utvecklarflöden snarare än att bara lägga till ytterligare en prenumerationsrad.

Instrumentpanelen blev allmänt tillgänglig i februari 2026 och nås via ditt företagskonto → AI Controls → Copilot → Metrics → Copilot usage metrics i fliken Insights.

Exempel på Copilot Usage Metrics Dashboard från github.blog

Vad API:et mäter

Usage Metrics API exponerar flera kategorier av operativ telemetri.

Vanliga mätetal inkluderar:

• Aktiva användare
• Föreslagna kodrader vs accepterade kodrader
• IDE-användningsmönster
• Modellanvändning
• Agentinteraktioner
• Språkfördelning

Detta ger organisationer en mycket mer nyanserad bild än enkla platsantal.

Ett team med 100 tilldelade platser men bara 15 aktiva användare har en helt annan adoptionsprofil än ett team med konsekvent daglig användning och hög acceptansgrad.

API-övergången 2026

GitHub avvecklade flera tidigare telemetri-API:er (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) under övergångsperioden 2025 till 2026, med full avveckling i april 2026.

Dessa inkluderade:

• Det föråldrade Metrics API
• Feature Engagement-API:er
• Direct Data Access-API:er

De nyare Usage Metrics-endpoints, tillgängliga sedan februari 2026, konsoliderade dessa rapporteringssystem till en mer enhetlig modell, vilket inkluderar versionshantering av dessa API:er vid brytande ändringar.

Detta är viktigt eftersom många äldre blogginlägg och GitHub-exempel fortfarande refererar till utfasade endpoints. När du arbetar med Usage Metrics API, verifiera alltid dokumentationen mot GitHubs senaste API-referenser innan du bygger automatisering kring det.

Fråga Usage Metrics API

Nu när vi förstår syftet med usage metrics API, låt oss prata om hur vi faktiskt använder det i praktiken.

Autentisering och behörigheter

GitHub Copilot Usage Metrics-endpoints kräver i allmänhet att du ställer in några behörigheter för din Personal Access Token (PAT). Detta kan göras antingen via klassisk PAT eller finkornig PAT.

• För klassiska PAT behöver din företagsadministratör ge dig följande behörigheter: manage_billing:copilot och read:org. 

• För finkorniga åtkomsttoken måste du säkerställa att du använder GitHub-appens användaråtkomsttoken eller installationsåtkomsttoken med behörighetsuppsättningen Enterprise Copilot metrics enterprise permissions (read).

Vanligtvis föredras finkorniga token eftersom de minskar onödig exponering av behörigheter.

Endpoints på organisationsnivå

De två vanligaste rapporterna på organisationsnivå är:

• organization-1-day

• organization-28-day

Endagsrapport på organisationsnivå

Endagsrapporten fungerar bra för operativ övervakning och kortsiktig trendanalys. Historiska data finns tillgängliga tillbaka till 10 oktober 2025 och kan nås i upp till ett år från dagens datum.

Nedanstående curl-kommando anropar endagsrapportens metrisk-API och returnerar ett JSON-svar med nedladdningslänkar till användningsrapporterna. Du måste se till att inkludera YOUR_TOKEN för bearer-autentisering och välja en DAY för den specifika dag du vill ha rapporten för i formatet YYYY-MM-DD.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

URL:erna i download_links är signerade och tidsbegränsade, vilket betyder att de upphör att gälla strax efter hämtning. Ditt arbetsflöde måste hämta nedladdnings-URL:en och omedelbart ladda ner filen i samma körning; du kan inte spara dessa URL:er för senare användning.

Svaret du får kan endast innehålla download_links och report_day, men detta är det fulla potentiella schemat:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

28-dagarsrapport på organisationsnivå

28-dagarsrapporten hjälper till att identifiera bredare adoptionsmönster och långsiktiga användningsförändringar. Kommandona är mycket lika, med en liten ändring till 28-dagars-API:et.

Exempelbegäran:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Du får ett liknande svar, förutom att det kommer att finnas ett response_start_day och response_end_day.

Rapportstruktur på organisationsnivå

JSON-rapporterna för både endags- och 28-dagarsrapporter på organisationsnivå kan se ut så här:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

Som du ser ger detta en översikt på hög nivå över användarna inom en viss organisation, deras team och deras teamtaggar. 

Endpoints på användarnivå

Rapporter på användarnivå ger mer detaljerad inblick i adoptionen. Det betyder att du kan förstå hur individer använder Copilot på en mycket hög nivå.

Vanliga endpoints inkluderar:

• users-1-day

• users-28-day

• user-teams-1-day

Dessa rapporter hjälper administratörer att identifiera:

• Mycket aktiva användare
• Team med låg adoption
• Utbildningsmöjligheter
• Användningstrender på avdelningsnivå

Dessa begäranden liknar mycket endags- och 28-dagarsrapporterna på organisationsnivå; de pekar bara på ett annat API.

Endagsrapport på användarnivå

Exempel på anrop till users-1-day-API:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

28-dagarsrapport på användarnivå

Exempel på anrop till users-28-day-API:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Endagsrapport på nivån användare–team

Det finns också en endpoint user-teams-1-day, som mappar varje användare till deras teammedlemskap. Den innehåller inga användningsmått i sig; syftet är att fungera som join-nyckel när du vill aggregera per-användar-data efter team.

Rapportstruktur på användarnivå

Detaljnivån i dessa rapporter är mycket högre, eftersom de pekar på en viss användares användningsdata:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Dessa mätetal är mest värdefulla som signaler för adoption på teamnivå. Acceptansgrader och användningsräkningar är operativa signaler, inte mått på utvecklarkvalitet.

För de fulla potentiella mätetalen du kan se, besök GitHubs dokumentation för användningsdata för de mest uppdaterade mätningarna.

Rapporterna på användarnivå inkluderar CLI-interaktionsdata. Om dina team använder Copilot via kommandoraden täcker vår GitHub Copilot CLI Tutorial installation och vanliga arbetsflöden.

Bygga ett rapporteringsflöde för Copilot

Att anropa API:et manuellt är användbart för experiment och för att förstå schemat. För att bli handlingsbart är det bättre att skapa ett automatiserat arbetsflöde.

Team som får ut mest värde av Copilot Enterprise bygger vanligtvis lättviktiga rapportpipelines som kombinerar användningstelemetri med interna ingenjörsmått.

Nyckelmått för att bevisa ROI

Alla Copilot-mått är inte lika viktiga. De mest användbara tenderar att vara:

• Tillväxt av aktiva användare
• Trender i acceptansgrad
• Föreslagen kontra bibehållen kod
• Förbättringar i PR-cykeltid
• Frekvens av IDE-engagemang

GitHub har publicerat riktmärken som:

• 55% snabbare uppgiftslösning
• 88% kodretentionsgrad

Dessa siffror visar betydande produktivitetsförbättringar. Dina resultat kommer att variera mellan team och arbetsflöden, vilket är precis varför Usage Metrics API finns. Ett backend-infrastrukturteam kan interagera med Copilot annorlunda än ett frontend-prototypteam.

Från rådata till en teamdashboard

Ett lättviktigt rapporteringsflöde ser ofta ut så här:

1. Schemalagt API-anrop
2. Lagra svar i en databas eller ett kalkylblad
3. Transformera data till rapporttabeller
4. Visualisera mätetal i en befintlig BI-plattform

Själva stacken är mindre viktig än konsekvensen.

Även ett enkelt arbetsflöde med schemalagda Python-skript och CSV-exporter kan ge användbar operativ insyn.

Exempelarkitektur:

GitHub API

  ↓

Schemalagt Python-skript

  ↓

PostgreSQL / CSV / Kalkylblad

 ↓

Power BI / Tableau / Looker

Avslutande tankar

GitHub Copilot Enterprise handlar egentligen om att bygga upp din infrastruktur för AI-redo kod. Spaces ger det organisatoriska sammanhanget som gör Copilot mer användbart i verkliga ingenjörsmiljöer. Usage Metrics API ger den telemetri som behövs för att förstå om adoptionen lyckas.

De organisationer som får starkast resultat från Copilot Enterprise tenderar att dela ett gemensamt mönster:

• De kuraterar internt sammanhang noggrant
• De övervakar adoption kontinuerligt
• De tar Copilot-styrning på allvar
• De mäter utfall istället för att anta produktivitetsvinster

Det tankesättet är mycket viktigare än att bara tilldela platser.

Om du vill fördjupa dina Copilot- och AI-kunskaper rekommenderar jag vår kurs Software Development with GitHub Copilot eller hela kompetensspåret AI for Software Engineering.