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, organisatorisk kontext 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å förmågor är viktigast i praktiken:

1. Anpassad organisatorisk kontext via Spaces
2. Organisationstäckande telemetri via Usage Metrics API

Dessa två funktioner förflyttar Copilot från ”smart autokomplettering” till något som liknar en intern AI-plattform för utveckling.

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

För en bredare översikt över 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-abonnemanget med ytterligare funktioner som:

• Organisationnivåns användningsmetrik
• Utökade styrningskontroller
• Arv av policyer på företagsnivå
• Större tilldelning av premiumförfrågningar (1 000 jämfört med 300 i Business-nivån)
• Ytterligare modellåtkomst och -hantering

Enterprise kräver GitHub Enterprise Cloud utöver själva Copilot Enterprise-abonnemanget. Detta innebär en extra kostnad per användare, så säkerställ 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 på företagsnivå (/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 åtskillnaden är viktig eftersom många team initialt överinvesterar. De antar att Enterprise betyder ”bättre Copilot”, när verkligheten är att Enterprise främst lägger till verktyg för styrning och mätning.

Copilot Spaces: Anpassad kontext 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, distributionsflöden eller onboarding-dokumentation.

Spaces tillhandahåller en kuraterad organisatorisk kontext som Copilot kan referera till under konversationer och kodningsstöd.

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

• ”Hur strukturerar vi API-handlers internt?”
• ”Vilket autentiseringsbibliotek rekommenderar vårt plattformsteam?”
• ”Vilket distributionsflö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.

Avvecklingen av Knowledge Bases

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 föråldrad 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–2026.

Skapa och konfigurera Copilot Spaces

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

Den struktur du väljer tidigt tenderar att bli kvar. Jag har sett organisationer av misstag skapa ”dokumentationssprawl” i Spaces eftersom ingen fastställde ägarskapsregler 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. Dessa steg är liknande på Enterprise-nivå, med några olika sidor.

Ställa in ett Space

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

1. Navigera till sidan Copilot Spaces i ditt Enterprise-administrationsområde
2. Skapa ett nytt Space

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

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

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

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

En notering 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 repositoryn.

Efter konfiguration bör administratörer testa spacet 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 problemet oftast på:

• Saknade repositoryn
• Dålig dokumentationskvalitet
• Felaktiga behörigheter
• Otillräcklig indexeringstid

Delning och åtkomstkontroller

Spaces stöder två huvudsakliga synlighetsmodeller:

• Individuella Spaces
• Organisationstäckande Spaces

Medlemmar av 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öretagsgemensamma ramverk.

Ett vanligt misstag jag ofta ser är övercentralisering. Ett enda, gigantisk företagstäckande Space kan bli brusigt och svårt för Copilot att använda effektivt.

Organisera Spaces per team eller domän

Det finns ingen universellt korrekt organisationsstruktur.

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

Ett Space per team

Användbart när ingenjörsgrupper arbetar relativt självständigt.

Exempel:

• Plattformsutveckling
• Data engineering
• Mobilutveckling

Ett Space per produktområde

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

Exempel:

• Betalningar
• Analys
• Infrastruktur
• Kundplattform

Delat standard-space

Många organisationer underhåller ett separat delat Space för:

• Säkerhetsriktlinjer
• Kodningskonventioner
• Distributionsflöden
• Arkitekturststandarder

I praktiken fungerar hybrida tillvägagångssätt oftast bäst. Varje team kan få sitt eget space, med större standardspaces 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 tog bort under API-konsolideringen 2026. 

Utan tydliga mätvärden tappar organisationer snabbt insyn i om Copilot-adoptionen lyckas. Ledningen vill ha bevis på att investeringen förbättrar utvecklarflödena i stället för att bara lägga till ännu en prenumerationsrad.

Instrumentpanelen nådde allmän tillgänglighet i februari 2026 och är tillgänglig via ditt företagskonto → AI Controls → Copilot → Metrics → Copilot usage metrics på 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ätvärden 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 platssiffror.

Ett team med 100 tilldelade platser men bara 15 aktiva användare har en helt annan adoptionsprofil än ett 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–2026, med full avveckling i april 2026.

Dessa inkluderade:

• Det äldre Metrics API
• Feature Engagement-API:er
• Direct Data Access-API:er

De nyare Usage Metrics-endpointsen, tillgängliga sedan februari 2026, konsoliderade dessa rapportsystem till en mer enhetlig modell, som även inkluderar versionshantering av API:erna vid brytande ändringar.

Detta är viktigt eftersom många äldre blogginlägg och GitHub-exempel fortfarande refererar till föråldrade endpoints. När du arbetar med Usage Metrics API, verifiera alltid dokumentationen mot GitHubs senaste API-referenser innan du bygger automationsflöden 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 regel 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:er behöver du be din företagsadmin 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 behörighetsexponering.

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 upp till ett år från dagens datum.

Nedanstående curl-kommando anropar endagsrapportens metrics-API och returnerar ett JSON-svar med nedladdningslänkar till användningsrapporterna. Du måste se till att inkludera YOUR_TOKEN för Bearer-auth och välja en DAY för den specifika dag du vill hämta 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 kort 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 bara innehålla download_links och report_day, men detta är det fullständiga 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 väldigt lika, med en liten ändring för att använda 28-dagars-API:et.

Exempel på begä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 finns 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 ungefär 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 insyn i adoption. 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
• Utbildningsbehov
• Användningstrender på avdelningsnivå

Dessa begäranden är väldigt lika endags- och 28-dagarsrapporterna på organisationsnivå; de pekar bara på ett annat API.

Endagsrapport på användarnivå

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

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å users-28-day-API-anrop:

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å user-teams-nivå

Det finns också ett user-teams-1-day-endpoint som mappar varje användare till deras teammedlemskap. Det innehåller inga användningsmätvärden i sig; syftet är att fungera som en join-nyckel när du vill aggregera per-användardata per 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ätvärden är mest värdefulla som adoptionssignaler på teamnivå. Acceptansgrader och användningsantal är operativa signaler, inte mått på utvecklarkvalitet.

För de fullständiga potentiella mätvärdena du kan se, besök den GitHub-dokumentationen för användningsmetrik för de mest aktuella uppmätta mätvärdena.

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

Bygga ett Copilot-rapporteringsflöde

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

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

Viktiga mått för att bevisa ROI

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

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

GitHub har publicerat riktvärden såsom:

• 55 % snabbare slutförande av uppgifter
• 88 % kodretentionsgrad

Dessa siffror visar på betydande produktivitetsförbättringar. Dina resultat kommer att variera per team och arbetsflöde, vilket är precis därfö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 rapporteringstabeller
4. Visualisera mätvärden i en befintlig BI-plattform

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

Till och med 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 i grunden om att bygga upp din infrastruktur för AI-redo kod. Spaces ger den organisatoriska kontext som gör Copilot mer användbar i verkliga ingenjörsmiljöer. Usage Metrics API ger telemetrin 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 intern kontext noggrant
• De övervakar adoption kontinuerligt
• De tar Copilot-styrning på allvar
• De mäter utfall i stället för att anta produktivitetsvinster

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

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