GitHub Copilot Enterprise: een gids voor Spaces en de Usage Metrics API

Wat is GitHub Copilot Enterprise?

GitHub Copilot Enterprise staat bovenaan de hiërarchie van GitHub’s Copilot-abonnementen.

Vergeleken met GitHub Copilot Business of Pro+ legt Enterprise de nadruk op governance, organisatorische context en meetmogelijkheden. Het is ontworpen voor bedrijven met grote engineeringomgevingen, niet voor individuele developers of kleine teams.

Twee vaardigheden zijn in de praktijk het belangrijkst:

1. Aangepaste organisatorische context via Spaces
2. Telemetrie op organisatieniveau via de Usage Metrics API

Die twee functies verschuiven Copilot van “slimme autocomplete” naar iets dat meer lijkt op een intern AI-engineeringplatform.

De bedrijven die het meeste waarde halen uit GitHub Copilot Enterprise behandelen het als een essentieel onderdeel van hun interne infrastructuur. Ze configureren de organisatorische context zorgvuldig, meten adoptie continu en passen beleid aan op basis van gebruiksdata in plaats van aannames.

Voor een bredere kijk op GitHub’s ecosysteem raad ik onze gids Introduction to GitHub Products aan.

Hoe Enterprise verschilt van Business en Pro+

GitHub Copilot Enterprise breidt het Business-abonnement uit met extra functies zoals:

• Gebruiksstatistieken op organisatieniveau
• Uitgebreidere governance-controles
• Enterprise-brede beleids­overerving
• Grotere toewijzingen voor premiumverzoeken (1.000 vs 300 in de Business-laag)
• Extra modeltoegang en -beheer

Voor Enterprise heb je GitHub Enterprise Cloud nodig, naast het Copilot Enterprise-abonnement zelf. Dit brengt extra kosten per gebruiker met zich mee, dus zorg dat je organisatie echt behoefte heeft aan governance, telemetrie en beheer op enterprise-niveau.

Opmerking: Abonnees op Business hebben toegang tot de Usage Metrics API op organisatieniveau (/orgs/{org}/…). Enterprise-abonnees hebben daarnaast toegang tot enterprisewijde, geaggregeerde rapporten (/enterprises/{enterprise}/…) die alle organisaties in één overzicht tonen.

Voor wie GitHub Copilot Enterprise bedoeld is

GitHub Copilot Enterprise richt zich op organisaties die al een volwassen GitHub-omgeving draaien.

Typische Enterprise-klanten zijn onder meer:

• Grote engineeringorganisaties
• Gereguleerde sectoren
• Platformengineeringgroepen met meerdere teams
• Bedrijven met interne ontwikkelstandaarden
• Organisaties die gecentraliseerde governance vereisen

Let op: dit verbetert niet automatisch de prestaties van Copilot. Dit onderscheid is belangrijk, omdat veel teams in het begin te groot inkopen. Ze gaan ervan uit dat Enterprise gelijkstaat aan “betere Copilot”, terwijl Enterprise in de praktijk vooral governance- en meettools toevoegt.

Copilot Spaces: Aangepaste context voor je organisatie

Copilot Spaces lossen een van de grootste zwaktes op van generieke AI-codeassistenten.

Out of the box begrijpt Copilot publieke programmeerkennis behoorlijk goed. Het begrijpt niet automatisch jullie interne API’s, architectuurkeuzes, codeconventies, deployment-workflows of onboardingdocumentatie.

Spaces bieden een gecureerde organisatorische context waarnaar Copilot kan verwijzen tijdens gesprekken en code-assistentie.

Concreet helpen Spaces Copilot om vragen te beantwoorden als:

• “Hoe structureren we intern API-handlers?”
• “Welke authenticatiebibliotheek raadt ons platformteam aan?”
• “Welke deployment-workflow moet deze microservice gebruiken?”
• “Welke naamgevingsconventies hanteert ons backendteam?”

Wat Spaces ondersteunen

Spaces ondersteunen een breder scala aan organisatorische content dan het oudere Knowledge Bases-systeem.

Ondersteunde contenttypes zijn onder meer:

• Codebestanden
• Markdown-documentatie
• JSON-bestanden
• Geuploade bestanden
• Afbeeldingen
• GitHub Issues
• Pull requests

Elk contenttype draagt op een andere manier bij.

Codebestanden helpen Copilot om implementatiepatronen te begrijpen. Markdown-bestanden bieden architectuuruitleg en onboardingrichtlijnen. Pull requests tonen reviewdiscussies en historische engineeringbeslissingen. Die combinatie geeft Copilot beter inzicht in de ontwikkelpraktijken van je organisatie.

Een subtiel maar belangrijk punt is dat Spaces niet simpelweg vector­databases zijn die aan GitHub zijn gekoppeld. Ze bevatten deel­instellingen en organisatorische governance-workflows die zijn ontworpen voor enterprise-omgevingen.

Het einde van Knowledge Bases

GitHub heeft de oudere functie Copilot Knowledge Bases uitgefaseerd op 1 november 2025.

Spaces vervingen Knowledge Bases met:

• Bredere contentondersteuning
• Betere deel­instellingen
• Verbeterd beheer
• Flexibeler beheer op organisatieniveau

Je komt nog steeds verouderde documentatie en blogposts tegen die naar Knowledge Bases verwijzen. Wees voorzichtig met oudere tutorials, want veel eindpunten en workflows zijn veranderd tijdens de overgangsperiode van 2025 tot 2026.

Copilot Spaces maken en configureren

Vanuit beheeroogpunt zijn Copilot Spaces vrij eenvoudig aan te maken. De uitdaging zit ’m in het beheren van tientallen of honderden ervan over teams heen.

De structuur die je vroeg kiest, blijft vaak hangen. Ik heb organisaties per ongeluk “documentatiespagaat” zien creëren binnen Spaces omdat niemand vooraf eigenaarschapsregels vastlegde.

Iedereen kan een Copilot Space maken, dus laten we er één testen in onze persoonlijke repo. Deze stappen zijn vergelijkbaar op Enterprise-niveau, met een paar andere pagina’s.

Een Space instellen

Een Space maken volgt doorgaans deze workflow:

1. Ga naar de Copilot Spaces-pagina in je Enterprise-beheeromgeving
2. Maak een nieuwe Space

3. Selecteer repositories en contentbronnen, inclusief MCP’s en andere nuttige tools

4. Bronnen toevoegen kan via de knop “+ Add sources” aan de rechterkant

5. Je kunt er op dit moment voor kiezen om de space te delen of de deel­instellingen in te stellen

6. Controleer of Copilot tijdens chatinteracties naar de content kan verwijzen

Een opmerking voor enterprise-gebruikers: je beheerder kan het delen van persoonlijke Spaces uitschakelen. Als je dus je eigen account gebruikt, kan dat je mogelijkheid om een Copilot Space te delen die geen repositories van de enterprise gebruikt, beïnvloeden.

Na de setup moeten beheerders de Space testen met praktische prompts.

Bijvoorbeeld:

How does our authentication middleware handle token refresh logic?

Of:

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

Als Copilot geen nauwkeurig antwoord kan geven, is het probleem meestal een van de volgende:

• Ontbrekende repositories
• Slechte documentatiekwaliteit
• Onjuiste permissies
• Onvoldoende indexeringstijd

Delen en toegangsbeheer

Spaces ondersteunen twee hoofdmodellen voor zichtbaarheid:

• Individuele Spaces
• Spaces op organisatieniveau

Leden van een enterprise kunnen hun individuele spaces laten beheren door de bredere enterprise-instellingen. Enterprise-beheerders kunnen ook centraal preview- en functiebeleid beheren. 

Privé-Spaces werken goed voor experimentele teams of gevoelige interne initiatieven. Spaces op organisatieniveau zijn logisch voor engineeringstandaarden, onboardingdocumentatie of bedrijfsbrede frameworks.

Een fout die ik vaak zie, is overcentralisatie. Één enorme, bedrijfsbrede Space kan ruiserig worden en lastig voor Copilot om effectief te gebruiken.

Spaces organiseren per team of domein

Er is geen universeel juiste organisatiestructuur.

Veelvoorkomende patronen zijn één space per team, één space per productgebied of gedeelde standaardspaces. Elk heeft een andere scope en gebruikt in feite dezelfde instellingenruimte anders.

Eén Space per team

Handig wanneer engineeringgroepen relatief zelfstandig opereren.

Voorbeelden:

• Platform engineering
• Data engineering
• Mobiele ontwikkeling

Eén Space per productgebied

Handig voor organisaties die eerder rond producten dan afdelingen zijn gestructureerd.

Voorbeelden:

• Payments
• Analytics
• Infrastructuur
• Klantplatform

Gedeelde standaardspace

Veel organisaties onderhouden een aparte gedeelde Space voor:

• Beveiligingsrichtlijnen
• Codeconventies
• Deployment-workflows
• Architectuurstandaarden

In de praktijk werken hybride benaderingen meestal het best. Elk team krijgt bijvoorbeeld een eigen space, met grotere standaardspaces die tussen teams worden gedeeld.

De Copilot Usage Metrics API

Spaces lossen het contextprobleem op. De Usage Metrics API lost het meetprobleem op. Deze verving meerdere oudere telemetriesystemen die GitHub buiten gebruik stelde tijdens de API-consolidatie van 2026. 

Zonder heldere metingen verliezen organisaties snel het zicht op of de Copilot-adoptie slaagt. Leidinggevenden willen bewijs dat de investering ontwikkelworkflows verbetert in plaats van alleen maar een extra abonnementsregel toe te voegen.

Het dashboard werd algemeen beschikbaar in februari 2026 en is toegankelijk via je enterpriseaccount → AI Controls → Copilot → Metrics → Copilot usage metrics in het tabblad Insights.

Voorbeeld van Copilot Usage Metrics-dashboard van github.blog

Wat de API meet

De Usage Metrics API stelt verschillende categorieën operationele telemetrie bloot.

Veelvoorkomende metrics zijn onder meer:

• Actieve gebruikers
• Voorgestelde regels code vs geaccepteerde regels code
• IDE-gebruikspatronen
• Modelgebruik
• Agentinteracties
• Taalsplitsingen

Dit geeft organisaties een veel genuanceerder beeld dan simpele seat-aantallen.

Een team met 100 toegewezen seats maar slechts 15 actieve gebruikers heeft een heel ander adoptieprofiel dan een team met consistent dagelijks gebruik en hoge acceptatiepercentages.

De API-overgang van 2026

GitHub heeft meerdere eerdere telemetrie-API’s (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) uitgefaseerd tijdens de overgangsperiode 2025 tot 2026, en volledig stopgezet per april 2026.

Dit omvatte:

• De legacy Metrics API
• Feature Engagement-API’s
• Direct Data Access-API’s

De nieuwere Usage Metrics-eindpunten, beschikbaar sinds februari 2026, consolideerden die rapportagesystemen in een meer uniform model, inclusief versiebeheer van deze API’s bij breaking changes.

Dit is belangrijk omdat veel oudere blogposts en GitHub-voorbeelden nog steeds naar verouderde eindpunten verwijzen. Controleer bij gebruik van de Usage Metrics API altijd de documentatie aan de hand van GitHub’s meest recente API-referenties voordat je er automatisering omheen bouwt.

De Usage Metrics API bevragen

Nu we het doel van de Usage Metrics API begrijpen, bespreken we hoe je deze in de praktijk gebruikt.

Authenticatie en permissies

Voor de GitHub Copilot Usage Metrics-eindpunten moet je doorgaans een paar permissies instellen voor je Personal Access Token (PAT). Dit kan via de klassieke PAT of via een fijnmazige PAT.

• Voor klassieke PAT’s moet je enterprise-beheerder je de volgende permissies geven: manage_billing:copilot en read:org. 

• Voor fijnmazige toegangstokens moet je ervoor zorgen dat je de GitHub app user access token of installation access token gebruikt met de permissie set Enterprise Copilot metrics enterprise permissions (read).

Meestal verdienen fijnmazige tokens de voorkeur omdat ze onnodige blootstelling van permissies verminderen.

Eindpunten op organisatieniveau

De twee meest gebruikte rapporten op organisatieniveau zijn:

• organization-1-day

• organization-28-day

Eendaags rapport op organisatieniveau

Het eendaagse rapport werkt goed voor operationele monitoring en analyse van kortetermijntrends. Historische data is beschikbaar terug tot 10 oktober 2025 en kan tot een jaar vanaf de huidige datum worden geraadpleegd.

Onderstaand curl-commando roept de eendaagse metrics-API aan en geeft een JSON-response met downloadlinks voor de gebruiksrapporten. Zorg dat je YOUR_TOKEN opneemt voor de bearer-auth en kies een DAY voor de specifieke dag die je wilt opvragen in YYYY-MM-DD-formaat.

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"

De URL’s in download_links zijn gesigneerd en tijdgebonden, wat betekent dat ze kort na het ophalen verlopen. Je workflow moet de download-URL ophalen en het bestand direct in dezelfde run binnenhalen; je kunt deze URL’s niet opslaan voor later gebruik.

De response die je krijgt kan alleen download_links en report_day bevatten, maar dit is het volledige potentiële schema:

{
  "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-daags rapport op organisatieniveau

Het 28-daagse rapport helpt om bredere adoptiepatronen en langetermijnwijzigingen in gebruik te identificeren. De opdrachten zijn erg vergelijkbaar, met een kleine aanpassing om de 28-daagse API te gebruiken.

Voorbeeldverzoek:

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

Je krijgt een vergelijkbare response, behalve dat er een response_start_day en response_end_day zullen zijn.

Structuur van rapporten op organisatieniveau

De JSON-rapporten voor zowel het eendaagse als het 28-daagse organisatierapport kunnen er zo uitzien:

[
  {
    "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"
  }
]

Zoals je ziet geeft dit je een overzicht op hoog niveau van de gebruikers binnen een bepaalde organisatie, hun team en hun teamtags. 

Eindpunten op gebruikersniveau

Rapporten op gebruikersniveau bieden meer gedetailleerd inzicht in adoptie. Zo kun je op hoog niveau begrijpen hoe individuen Copilot gebruiken.

Veelgebruikte eindpunten zijn onder meer:

• users-1-day

• users-28-day

• user-teams-1-day

Deze rapporten helpen beheerders om te identificeren:

• Zeer actieve gebruikers
• Teams met lage adoptie
• Trainingskansen
• Gebruikstrends op afdelingsniveau

Deze requests lijken sterk op de eendaagse en 28-daagse rapporten op organisatieniveau; ze wijzen alleen naar een ander API-eindpunt.

Eendaags rapport op gebruikersniveau

Voorbeeld van een users-1-day-API-aanroep:

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-daags rapport op gebruikersniveau

Voorbeeld van een users-28-day-API-aanroep:

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

Eendaags rapport op user-teams-niveau

Er is ook een user-teams-1-day-eindpunt, dat elke gebruiker koppelt aan zijn teamlidmaatschappen. Het bevat zelf geen gebruiksstatistieken; het doel is te dienen als joinkey wanneer je per-gebruikerdata per team wilt aggregeren.

Structuur van rapporten op gebruikersniveau

Het detailniveau in deze rapporten is veel hoger, aangezien ze verwijzen naar de gebruiksdata van een specifieke gebruiker:

[{
  "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
}]

Deze metrics zijn het waardevolst als adoptiesignalen op teamniveau. Acceptatiepercentages en gebruiksaantallen zijn operationele signalen, geen metingen van ontwikkelkwaliteit.

Voor het volledige potentieel aan metrics die je kunt tegenkomen, ga je naar de GitHub usage metrics data documentation voor de meest actuele gemeten metrics.

De rapporten op gebruikersniveau bevatten CLI-interactiedata. Als je teams Copilot via de command line gebruiken, behandelt onze GitHub Copilot CLI Tutorial de setup en veelvoorkomende workflows.

Een Copilot-rapportageworkflow bouwen

De API handmatig aanroepen is nuttig om te experimenteren en het schema te begrijpen. Voor actiegerichte inzichten maak je beter een geautomatiseerde workflow.

Teams die het meeste waarde uit Copilot Enterprise halen, bouwen doorgaans lichte rapportagepijplijnen die gebruikstelemetrie combineren met interne engineeringmetrics.

Kernmetrics om ROI te bewijzen

Niet elke Copilot-metric is even belangrijk. De meest nuttige metrics zijn vaak:

• Groei van actieve gebruikers
• Trends in acceptatiepercentages
• Voorgestelde versus behouden code
• Verbeteringen in PR-cycletijd
• Frequentie van IDE-betrokkenheid

GitHub heeft benchmarks gepubliceerd zoals:

• 55% snellere taakafronding
• 88% codebehoud

Die cijfers laten aanzienlijke productiviteitsverbeteringen zien. Jouw resultaten verschillen per team en workflow, en dáárom bestaat de Usage Metrics API. Een backend-infrastructuurteam gaat anders met Copilot om dan een frontend-prototypeteam.

Van ruwe data naar een teamdashboard

Een lichte rapportageworkflow ziet er vaak zo uit:

1. Geplande API-aanroep
2. Responses opslaan in een database of spreadsheet
3. Data transformeren naar rapportagetabellen
4. Metrics visualiseren in een bestaand BI-platform

De gekozen stack is minder belangrijk dan consistentie.

Zelfs een eenvoudige workflow met geplande Python-scripts en CSV-exports kan nuttige operationele zichtbaarheid bieden.

Voorbeeldarchitectuur:

GitHub API

  ↓

Gepland Python-script

  ↓

PostgreSQL / CSV / Spreadsheet

  ↓

Power BI / Tableau / Looker

Tot slot

GitHub Copilot Enterprise draait er uiteindelijk om je infrastructuur klaar te stomen voor AI-ondersteunde code. Spaces bieden de organisatorische context die Copilot nuttiger maakt in echte engineeringomgevingen. De Usage Metrics API levert de telemetrie die nodig is om te begrijpen of de adoptie slaagt.

De organisaties die de sterkste resultaten met Copilot Enterprise behalen, volgen doorgaans een vast patroon:

• Ze cureren interne context zorgvuldig
• Ze monitoren adoptie continu
• Ze nemen Copilot-governance serieus
• Ze meten uitkomsten in plaats van productiviteitswinst te veronderstellen

Die mindset is veel belangrijker dan simpelweg seats toewijzen.

Als je je Copilot- en AI-skills wilt verdiepen, raad ik onze cursus Software Development with GitHub Copilot aan of het volledige skill track AI for Software Engineering.