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+ ligt bij Enterprise de nadruk sterk op governance, organisatiecontext en meetmogelijkheden. Het is ontworpen voor bedrijven met grote engineeringomgevingen, niet voor individuele developers of kleine teams.

Twee voornamelijk belangrijke mogelijkheden in de praktijk:

1. Aangepaste organisatiecontext via Spaces
2. Organisatiebrede telemetrie via de Usage Metrics API

Die twee features verschuiven Copilot van “slim automatisch aanvullen” naar iets dat dichter in de buurt komt van een intern AI-engineeringplatform.

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

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

Hoe Enterprise verschilt van Business en Pro+

GitHub Copilot Enterprise bouwt voort op het Business-abonnement met extra features zoals:

• Gebruiksgemeten op organisatieniveau
• Uitgebreide governance-controls
• Enterprise-brede beleids­overerving
• Grotere toewijzing voor premiumverzoeken (1.000 vs 300 in de Business-laag)
• Extra modeltoegang en -beheer

Enterprise vereist GitHub Enterprise Cloud naast het Copilot Enterprise-abonnement zelf. Dit brengt extra kosten per gebruiker met zich mee, dus controleer of je organisatie echt behoefte heeft aan governance, telemetrie en beheer op enterpriseniveau.

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

Voor wie GitHub Copilot Enterprise is

GitHub Copilot Enterprise richt zich op organisaties die al met volwassen GitHub-omgevingen werken.

Typische Enterprise-klanten zijn onder andere:

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

Let op: dit verbetert niet automatisch de prestaties van Copilot. Die nuance is belangrijk omdat veel teams in het begin te veel 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 van generieke AI-codeassistenten op.

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

Spaces bieden een zorgvuldig samengestelde organisatiecontext waar Copilot tijdens gesprekken en code-assistentie naar kan verwijzen.

In de praktijk helpen Spaces Copilot om vragen te beantwoorden als:

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

Wat Spaces ondersteunen

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

Ondersteunde contenttypen zijn onder meer:

• Codebestanden
• Markdown-documentatie
• JSON-bestanden
• Geüploade bestanden
• Afbeeldingen
• GitHub Issues
• Pull requests

Elk contenttype draagt anders bij.

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

Een subtiel maar belangrijk punt is dat Spaces niet simpelweg vectordatabanken zijn die aan GitHub zijn gekoppeld. Ze bevatten deelcontroles en governance-workflows op organisatieniveau die zijn ontworpen voor enterprisecases.

De sunset van Knowledge Bases

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

Spaces vervingen Knowledge Bases met:

• Bredere contentondersteuning
• Betere deelcontroles
• Verbeterd beheer
• Flexibeler beheer op organisatieniveau

Je zult nog verouderde documentatie en blogposts vinden die naar Knowledge Bases verwijzen. Wees voorzichtig met oudere tutorials, want veel eindpunten en workflows zijn veranderd in de overgangsperiode 2025–2026.

Copilot Spaces maken en configureren

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

De structuur die je in het begin kiest, blijft meestal hangen. Ik heb organisaties per ongeluk “documentatiesprawl” zien creëren binnen Spaces omdat niemand vooraf eigenaarschapsregels vaststelde.

Iedereen kan een Copilot Space maken, dus laten we er een aanmaken in onze persoonlijke repo. Deze stappen lijken op enterpriseniveau, 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 ervoor kiezen om de space te delen of in dit stadium de deelinstellingen in te stellen

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

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

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 niet nauwkeurig kan antwoorden, is de oorzaak meestal een van de volgende:

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

Delen en toegangsbeheer

Spaces ondersteunen twee hoofdmodellen voor zichtbaarheid:

• Individuele Spaces
• Organisatiebrede Spaces

Leden van een enterprise kunnen hun individuele spaces laten beheren door de bredere enterpr ise-instellingen. Enterprise-beheerders kunnen ook centraal beleid voor preview en featurebeschikbaarheid beheren. 

Privéspaces werken goed voor experimentele teams of gevoelige interne initiatieven. Organisatiebrede Spaces zijn logisch voor engineeringstandaarden, onboardingdocumentatie of organisatiebrede frameworks.

Een fout die ik vaak zie, is overmatige centralisatie. Eén gigantische, organisatiebrede Space kan rumoerig 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 Space-instellingen op een andere manier.

Eén Space per team

Handig wanneer engineeringgroepen relatief zelfstandig opereren.

Voorbeelden:

• Platformengineering
• Data-engineering
• Mobile development

Eén Space per productgebied

Handig voor organisaties die zijn ingedeeld rond producten in plaats van afdelingen.

Voorbeelden:

• Payments
• Analytics
• Infrastructuur
• Klantplatform

Gedeelde standaardspace

Veel organisaties onderhouden een aparte gedeelde Space voor:

• Beveiligingsrichtlijnen
• Codeerconventies
• Deployment-workflows
• Architectuurstandaarden

In de praktijk werken hybride aanpakken meestal het best. Elk team kan een eigen space krijgen, 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 verschillende oudere telemetriesystemen die GitHub tijdens de API-consolidatie van 2026 heeft uitgefaseerd. 

Zonder duidelijke metingen verliezen organisaties snel het zicht op of de adoptie van Copilot slaagt. Leidinggevenden willen bewijs dat de investering ontwikkelworkflows verbetert in plaats van alleen een extra abonnement te zijn.

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

Voorbeeld van het Copilot Usage Metrics-dashboard op github.blog

Wat de API meet

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

Veelgebruikte metrics zijn onder andere:

• Actieve gebruikers
• Voorgestelde regels code vs geaccepteerde regels code
• IDE-gebruiks­patronen
• Modelgebruik
• Agentinteracties
• Taalverdeling

Dit geeft organisaties een veel genuanceerder beeld dan simpelweg 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 in 2026

GitHub heeft meerdere eerdere telemetrie-API’s (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) uitgefaseerd in de overgangsperiode 2025–2026, met een volledige sunset in 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, hebben die rapportagesystemen samengebracht in een meer uniform model, inclusief versies voor het geval er breaking changes zijn.

Dit is belangrijk omdat veel oudere blogposts en GitHub-voorbeelden nog naar verouderde eindpunten verwijzen. Wanneer je met de Usage Metrics API werkt, verifieer de documentatie altijd 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 permissieset Enterprise Copilot metrics enterprise permissions (read).

Meestal verdienen fijnmazige tokens de voorkeur omdat ze onnodige permissieblootstelling verminderen.

Eindpunten op organisatieniveau

De twee meest voorkomende rapporten op organisatieniveau zijn:

• organization-1-day

• organization-28-day

Rapport van één dag op organisatieniveau

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

Onderstaande curl-opdracht roept de metric-API voor het eendaagse rapport aan en retourneert een JSON-respons met downloadlinks voor de gebruiksrapporten. Zorg dat je YOUR_TOKEN opneemt voor bearer-auth en een DAY kiest voor de specifieke dag die je wilt, in het 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 ophalen verlopen. Je workflow moet de download-URL ophalen en het bestand direct in dezelfde run binnenhalen; je kunt deze URL’s niet voor later bewaren.

De respons die je krijgt bevat mogelijk alleen download_links en report_day, 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"
  ]
}

Rapport van 28 dagen op organisatieniveau

Het 28-dagenrapport helpt bredere adoptiepatronen en langetermijnveranderingen te identificeren. De opdrachten zijn vergelijkbaar, met een kleine wijziging naar de 28-dagen-API.

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 respons, 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-dagenrapport op organisatieniveau 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 hoogoverzicht van de gebruikers binnen een bepaalde organisatie, hun team en hun teamtags. 

Eindpunten op gebruikersniveau

Rapporten op gebruikersniveau geven fijnmaziger inzicht in adoptie. Dit betekent dat je op hoofdlijnen kunt begrijpen hoe individuen Copilot gebruiken.

Veelvoorkomende eindpunten zijn:

• 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 verzoeken lijken sterk op de eendaagse en 28-dagenrapporten op organisatieniveau; ze wijzen simpelweg naar een ander API-pad.

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-dagenrapport 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 het niveau user-teams

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

Structuur van rapporten op gebruikersniveau

Het detailniveau in deze rapporten is veel hoger, omdat 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 vooral waardevol als signalen voor adoptie op teamniveau. Acceptatiepercentages en gebruiksaantallen zijn operationele signalen, geen metingen van ontwikkelkwaliteit.

Voor het volledige potentieel aan metrics dat je kunt tegenkomen, bekijk de GitHub-datadocumentatie over usage metrics voor de meest actuele gemeten metrics.

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

Een Copilot-rapportageworkflow bouwen

De API handmatig aanroepen is nuttig om te experimenteren en het schema te begrijpen. Wil je er echt iets mee doen, bouw dan beter een geautomatiseerde workflow.

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

Kernmetrics om ROI te bewijzen

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

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

GitHub heeft benchmarks gepubliceerd zoals:

• 55% snellere taakafronding
• 88% coderetentie

Die cijfers laten aanzienlijke productiviteitsverbeteringen zien. Je resultaten variëren per team en workflow, en precies daarom bestaat de Usage Metrics API. Een backend-infrastructuurteam werkt anders met Copilot dan een frontend-prototypingteam.

Van ruwe data naar een teampaneel

Een lichte rapportageworkflow ziet er vaak zo uit:

1. Geplande API-aanroep
2. Respons 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 simpele workflow met geplande Python-scripts en CSV-exports kan waardevol operationeel inzicht bieden.

Voorbeeldarchitectuur:

GitHub API

  ↓

Gepland Python-script

  ↓

PostgreSQL / CSV / Spreadsheet

  ↓

Power BI / Tableau / Looker

Tot slot

GitHub Copilot Enterprise draait in wezen om het uitbouwen van je infrastructuur voor AI-ready code. Spaces bieden de organisatiecontext 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 halen met Copilot Enterprise volgen vaak een herkenbaar 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 alleen seats toewijzen.

Wil je je Copilot- en AI-skills verdiepen, volg dan onze cursus Software Development with GitHub Copilot of het complete vaardigheidstraject AI for Software Engineering.