GitHub Copilot Enterprise: Ein Leitfaden zu Spaces und der Usage Metrics API

Was ist GitHub Copilot Enterprise?

GitHub Copilot Enterprise steht an der Spitze der Copilot-Plan-Hierarchie von GitHub.

Im Vergleich zu GitHub Copilot Business oder Pro+ liegt der Fokus bei Enterprise stark auf Governance, organisatorischem Kontext und Messbarkeit. Es ist für Unternehmen mit großen Engineering-Landschaften konzipiert – nicht für einzelne Entwickler oder kleine Teams.

Zwei Fähigkeiten sind in der Praxis am wichtigsten:

1. Individueller Organisationskontext über Spaces
2. Unternehmensweite Telemetrie über die Usage Metrics API

Diese beiden Funktionen machen aus Copilot mehr als nur „smarte Autovervollständigung“ – es wird zu einer internen KI-Engineering-Plattform.

Unternehmen, die den größten Nutzen aus GitHub Copilot Enterprise ziehen, behandeln es als zentralen Bestandteil ihrer internen Infrastruktur. Sie pflegen den Organisationskontext sorgfältig, messen Adoption fortlaufend und passen Richtlinien auf Basis von Nutzungsdaten an – nicht nach Bauchgefühl.

Für einen breiteren Überblick über das GitHub-Ökosystem empfehle ich unseren Leitfaden Introduction to GitHub Products.

Wie sich Enterprise von Business und Pro+ unterscheidet

GitHub Copilot Enterprise erweitert das Business-Abo um zusätzliche Features wie:

• Nutzungsmetriken auf Organisationsebene
• Erweiterte Governance-Kontrollen
• Unternehmensweite Richtlinienvererbung
• Größere Premium-Anfragekontingente (1.000 vs. 300 im Business-Tarif)
• Zusätzlichen Modellzugriff und -verwaltung

Enterprise erfordert neben dem Copilot-Enterprise-Abo auch GitHub Enterprise Cloud. Das verursacht zusätzliche Kosten pro Nutzer. Prüfe daher, ob deine Organisation wirklich Governance, Telemetrie und Administration auf Enterprise-Niveau benötigt.

Hinweis: Business-Abonnenten greifen auf die Usage Metrics API auf Organisationsebene zu (/orgs/{org}/…). Enterprise-Abonnenten erhalten zusätzlich unternehmensweite aggregierte Reports (/enterprises/{enterprise}/…), die alle Organisationen in einer Ansicht abdecken.

Für wen GitHub Copilot Enterprise gedacht ist

GitHub Copilot Enterprise richtet sich an Organisationen, die bereits reife GitHub-Umgebungen betreiben.

Typische Enterprise-Kunden sind:

• Große Engineering-Organisationen
• Regulierte Branchen
• Plattform-Engineering-Gruppen mit mehreren Teams
• Unternehmen mit internen Entwicklungsstandards
• Organisationen mit zentraler Governance

Beachte, dass dies die Performance von Copilot nicht automatisch verbessert. Diese Unterscheidung ist wichtig, weil viele Teams anfangs zu groß einkaufen. Sie setzen „Enterprise = besseres Copilot“ gleich, dabei liefert Enterprise vor allem zusätzliche Governance- und Messwerkzeuge.

Copilot Spaces: Individueller Kontext für deine Organisation

Copilot Spaces lösen eine der größten Schwächen allgemeiner KI-Coding-Assistenten.

Out of the box versteht Copilot öffentliches Programmierwissen recht gut. Es versteht jedoch nicht automatisch eure internen APIs, Architekturentscheidungen, Codekonventionen, Deployment-Workflows oder Onboarding-Dokumentation.

Spaces liefern einen kuratierten Organisationskontext, auf den sich Copilot in Unterhaltungen und bei der Codeunterstützung beziehen kann.

Konkret helfen Spaces Copilot, Fragen wie diese zu beantworten:

• „Wie strukturieren wir intern unsere API-Handler?“
• „Welche Authentifizierungsbibliothek empfiehlt unser Plattformteam?“
• „Welchen Deployment-Workflow soll dieser Microservice nutzen?“
• „Welche Namenskonventionen nutzt unser Backend-Team?“

Was Spaces unterstützen

Spaces unterstützen ein breiteres Spektrum an Organisationsinhalten als das ältere Knowledge-Bases-System.

Unterstützte Inhaltstypen sind:

• Code-Dateien
• Markdown-Dokumentation
• JSON-Dateien
• Hochgeladene Dateien
• Bilder
• GitHub Issues
• Pull Requests

Jeder Inhaltstyp trägt auf eigene Weise bei.

Code-Dateien helfen Copilot, Implementierungsmuster zu verstehen. Markdown-Dateien liefern Architekturerklärungen und Onboarding-Hinweise. Pull Requests zeigen Review-Diskussionen und historische Engineering-Entscheidungen. Diese Kombination verschafft Copilot ein besseres Verständnis eurer Entwicklungspraktiken.

Ein subtiler, aber wichtiger Punkt: Spaces sind nicht einfach nur Vektordatenbanken an GitHub angedockt. Sie beinhalten Freigabekontrollen und Governance-Workflows, die für Enterprise-Umgebungen entwickelt wurden.

Das Ende der Knowledge Bases

GitHub hat die ältere Copilot-Funktion „Knowledge Bases“ am 1. November 2025 eingestellt.

Spaces haben Knowledge Bases ersetzt – mit:

• Breiterer Inhaltsunterstützung
• Besseren Freigabekontrollen
• Verbesserter Administration
• Flexiblerem Management auf Organisationsebene

Du wirst weiterhin veraltete Doku und Blogposts finden, die Knowledge Bases erwähnen. Sei vorsichtig mit älteren Tutorials, da viele Endpoints und Workflows im Übergang 2025 bis 2026 geändert wurden.

Copilot Spaces erstellen und konfigurieren

Aus Admin-Sicht sind Copilot Spaces relativ einfach anzulegen. Die Herausforderung liegt in der Verwaltung dutzender oder hunderter Spaces über Teams hinweg.

Die frühe Struktur bleibt meist bestehen. Ich habe gesehen, wie Organisationen ungewollt „Dokumentationswildwuchs“ in Spaces erzeugen, weil zu Beginn keine Ownership-Regeln definiert wurden.

Jede Person kann einen Copilot Space erstellen, also testen wir das in einem persönlichen Repo. Die Schritte sind auf Enterprise-Ebene ähnlich, nur mit ein paar anderen Seiten.

Ein Space einrichten

Das Anlegen eines Space folgt im Allgemeinen diesem Ablauf:

1. Zur Copilot-Spaces-Seite im Enterprise-Administrationsbereich navigieren
2. Neuen Space erstellen

3. Repositories und Inhaltsquellen auswählen, inklusive MCPs und anderer hilfreicher Tools

4. Quellen fügst du über den Button „+ Add sources“ auf der rechten Seite hinzu

5. Du kannst den Space jetzt teilen oder Freigabeeinstellungen setzen

6. Prüfen, ob Copilot die Inhalte in Chats referenzieren kann

Hinweis für Enterprise-Nutzende: Deine Administratorin bzw. dein Administrator kann das Teilen persönlicher Spaces deaktivieren. Wenn du dein eigenes Konto nutzt, kann das deine Möglichkeit einschränken, einen Copilot Space zu teilen, der nicht die Repositories des Enterprise nutzt.

Nach der Einrichtung sollten Admins den Space mit praxisnahen Prompts testen.

Zum Beispiel:

How does our authentication middleware handle token refresh logic?

Oder:

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

Wenn Copilot nicht korrekt antworten kann, liegt es meist an:

• Fehlenden Repositories
• Schlechter Dokumentationsqualität
• Falschen Berechtigungen
• Nicht ausreichender Indexierungszeit

Teilen und Zugriff steuern

Spaces unterstützen zwei Haupt- Sichtbarkeitsmodelle:

• Individuelle Spaces
• Organisationsweite Spaces

Mitglieder einer Enterprise können individuelle Spaces über die übergeordneten Enterprise-Einstellungen verwalten lassen. Enterprise-Admins können außerdem Vorschauen und Feature-Verfügbarkeit zentral steuern. 

Private Spaces sind gut für experimentelle Teams oder sensible interne Initiativen. Organisationsweite Spaces eignen sich für Engineering-Standards, Onboarding-Dokumente oder unternehmensweite Frameworks.

Ein häufiger Fehler ist zu starke Zentralisierung. Ein einziger, riesiger unternehmensweiter Space wird schnell laut und für Copilot schwer effektiv nutzbar.

Spaces nach Team oder Domäne organisieren

Es gibt keine universell richtige Organisationsstruktur.

Gängige Muster sind ein Space pro Team, ein Space pro Produktbereich oder geteilte Standards-Spaces. Jeder Ansatz hat einen anderen Zuschnitt und nutzt die gleichen Einstellungen unterschiedlich.

Ein Space pro Team

Sinnvoll, wenn Engineering-Gruppen relativ unabhängig arbeiten.

Beispiele:

• Plattform-Engineering
• Data Engineering
• Mobile-Entwicklung

Ein Space pro Produktbereich

Sinnvoll, wenn Organisationen eher entlang von Produkten als Abteilungen strukturiert sind.

Beispiele:

• Payments
• Analytics
• Infrastructure
• Customer Platform

Gemeinsamer Standards-Space

Viele Organisationen pflegen einen separaten, gemeinsamen Space für:

• Sicherheitsrichtlinien
• Codekonventionen
• Deployment-Workflows
• Architekturstandards

In der Praxis funktionieren hybride Ansätze am besten. Jedes Team bekommt seinen eigenen Space, während größere Standard-Spaces teamübergreifend geteilt werden.

Die Copilot Usage Metrics API

Spaces lösen das Kontextproblem. Die Usage Metrics API löst das Messproblem. Sie hat mehrere ältere Telemetriesysteme ersetzt, die GitHub während der API-Konsolidierung 2026 eingestellt hat. 

Ohne klare Messwerte verlieren Organisationen schnell den Überblick, ob die Copilot-Adoption gelingt. Das Management will Belege, dass die Investition Developer-Workflows verbessert und nicht nur eine weitere Aboposition darstellt.

Das Dashboard ist seit Februar 2026 allgemein verfügbar und erreichbar über dein Enterprise-Konto → AI Controls → Copilot → Metrics → Copilot usage metrics im Insights-Tab.

Copilot Usage Metrics Dashboard example from github.blog

Was die API misst

Die Usage Metrics API stellt mehrere Kategorien operativer Telemetrie bereit.

Häufige Metriken sind:

• Aktive Nutzende
• Vorgeschlagene Codezeilen vs. akzeptierte Codezeilen
• IDE-Nutzungsmuster
• Modellnutzung
• Agent-Interaktionen
• Sprachaufteilung

Das liefert ein deutlich nuancierteres Bild als einfache Sitzplatz-Zahlen.

Ein Team mit 100 zugewiesenen Lizenzen, aber nur 15 aktiven Nutzenden, hat ein ganz anderes Adoptionsprofil als eines mit konsistenter täglicher Nutzung und hoher Akzeptanzrate.

Der API-Übergang 2026

GitHub hat mehrere frühere Telemetrie-APIs (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) im Zeitraum 2025 bis 2026 eingestellt; endgültiges Ende war April 2026.

Dazu gehörten:

• Die Legacy-Metrics-API
• Feature-Engagement-APIs
• Direct-Data-Access-APIs

Die neueren Usage-Metrics-Endpoints, verfügbar seit Februar 2026, haben diese Reportingsysteme in ein einheitlicheres Modell konsolidiert – inklusive Versionierung für den Fall von Breaking Changes.

Das ist wichtig, weil viele ältere Blogposts und GitHub-Beispiele noch veraltete Endpoints referenzieren. Prüfe bei der Arbeit mit der Usage Metrics API immer die aktuelle GitHub-Referenz, bevor du Automatisierung darauf aufbaust.

Die Usage Metrics API abfragen

Jetzt, da wir den Zweck der Usage Metrics API verstehen, schauen wir uns an, wie wir sie in der Praxis nutzen.

Authentifizierung und Berechtigungen

Endpoints der GitHub Copilot Usage Metrics erfordern in der Regel ein paar Berechtigungen für deinen Personal Access Token (PAT). Das geht entweder über den klassischen PAT oder einen fein granularen PAT.

• Für klassische PATs muss dir deine Enterprise-Admin die folgenden Berechtigungen gewähren: manage_billing:copilot und read:org. 

• Für fein granulare Zugriffstoken stelle sicher, dass du das GitHub App User Access Token oder Installation Access Token mit der Berechtigung Enterprise Copilot metrics enterprise permissions (read) verwendest.

In der Regel sind fein granulare Tokens vorzuziehen, da sie unnötige Berechtigungsexposition reduzieren.

Endpoints auf Organisationsebene

Die beiden gängigsten Reports auf Organisationsebene sind:

• organization-1-day

• organization-28-day

Ein-Tages-Report auf Organisationsebene

Der Ein-Tages-Report eignet sich gut für operatives Monitoring und Kurzfristanalysen. Historische Daten sind ab dem 10. Oktober 2025 verfügbar und bis zu ein Jahr ab dem aktuellen Datum abrufbar.

Der folgende curl-Befehl ruft die Metrik-API für den Ein-Tages-Report auf und liefert eine JSON-Antwort mit Download-Links für die Nutzungsreports. Du musst YOUR_TOKEN für die Bearer-Auth setzen und ein DAY im Format YYYY-MM-DD wählen.

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"

Die URLs in download_links sind signiert und zeitlich begrenzt – sie verfallen kurz nach Abruf. Dein Workflow muss die Download-URL abrufen und die Datei in demselben Lauf herunterladen; du kannst diese URLs nicht für später speichern.

Die Antwort kann nur download_links und report_day enthalten, aber dies ist das vollständige Potenzial-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-Tage-Report auf Organisationsebene

Der 28-Tage-Report hilft, breitere Adoptionsmuster und längerfristige Nutzungsänderungen zu erkennen. Die Befehle sind sehr ähnlich, mit einer kleinen Anpassung auf die 28-Tage-API.

Beispielanfrage:

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 erhältst eine ähnliche Antwort, allerdings mit response_start_day und response_end_day.

Struktur der Reports auf Organisationsebene

Die JSON-Reports für Ein-Tages- und 28-Tage-Organisationsebene können so aussehen:

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

Wie du siehst, erhältst du einen Überblick über die Nutzer in einer bestimmten Organisation, ihr Team und deren Team-Tags. 

Endpoints auf Nutzerebene

Reports auf Nutzerebene liefern granularere Einblicke in die Adoption. So verstehst du auf hohem Niveau, wie einzelne Personen Copilot nutzen.

Gängige Endpoints sind:

• users-1-day

• users-28-day

• user-teams-1-day

Diese Reports helfen Administratoren, Folgendes zu identifizieren:

• Sehr aktive Nutzende
• Teams mit geringer Adoption
• Weiterbildungsbedarf
• Nutzungstrends auf Abteilungsebene

Die Anfragen ähneln stark den Ein-Tages- und 28-Tage-Reports auf Organisationsebene – sie zeigen lediglich auf andere APIs.

Ein-Tages-Report auf Nutzerebene

Beispielaufruf der 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-Tage-Report auf Nutzerebene

Beispielaufruf der 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

Ein-Tages-Report „user-teams“-Ebene

Es gibt auch einen user-teams-1-day-Endpoint, der jeden Nutzer seinen Teammitgliedschaften zuordnet. Er enthält keine Nutzungsmetriken; sein Zweck ist es, als Join-Key zu dienen, wenn du Nutzerdaten nach Teams aggregieren willst.

Struktur der Reports auf Nutzerebene

Der Detaillierungsgrad in diesen Reports ist deutlich höher, da sie auf die Nutzung einer bestimmten Person verweisen:

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

Diese Metriken sind am wertvollsten als Signale für die Team-Adoption. Akzeptanzraten und Nutzungshäufigkeiten sind operative Signale, keine Qualitätsmessungen für Entwickler.

Für das vollständige Spektrum möglicher Metriken siehe die GitHub Usage-Metrics-Dokumentation mit den aktuellsten Messwerten.

Die Reports auf Nutzerebene enthalten CLI-Interaktionsdaten. Wenn deine Teams Copilot über die Kommandozeile verwenden, deckt unser GitHub Copilot CLI Tutorial das Setup und gängige Workflows ab.

Einen Copilot-Reporting-Workflow aufbauen

Die API manuell aufzurufen ist hilfreich zum Experimentieren und für das Schema-Verständnis. Für umsetzbare Insights ist ein automatisierter Workflow besser.

Teams, die den größten Mehrwert aus Copilot Enterprise ziehen, bauen meist leichte Reporting-Pipelines, die Usage-Telemetrie mit internen Engineering-Metriken kombinieren.

Wichtige Metriken, um ROI nachzuweisen

Nicht jede Copilot-Metrik ist gleich relevant. Am nützlichsten sind meist:

• Wachstum aktiver Nutzender
• Trends bei Akzeptanzraten
• Vorgeschlagener vs. beibehaltener Code
• Verbesserungen der PR-Durchlaufzeit
• IDE-Nutzungsfrequenz

GitHub hat Benchmarks veröffentlicht wie:

• 55% schnellere Aufgabenerledigung
• 88% Code-Beibehaltungsraten

Diese Zahlen zeigen deutliche Produktivitätsgewinne. Deine Ergebnisse variieren je nach Team und Workflow – genau deshalb existiert die Usage Metrics API. Ein Backend-Infrastrukturteam interagiert anders mit Copilot als ein Frontend-Prototyping-Team.

Vom Rohdatenfeed zum Team-Dashboard

Ein schlanker Reporting-Workflow sieht oft so aus:

1. Geplanter API-Aufruf
2. Antworten in einer Datenbank oder Tabelle speichern
3. Daten in Reporting-Tabellen transformieren
4. Metriken in einer bestehenden BI-Plattform visualisieren

Der Tech-Stack ist weniger wichtig als die Regelmäßigkeit.

Schon ein einfacher Workflow mit geplanten Python-Skripten und CSV-Exports liefert nützliche operative Transparenz.

Beispielarchitektur:

GitHub API

  ↓

Geplantes Python-Skript

  ↓

PostgreSQL / CSV / Spreadsheet

  ↓

Power BI / Tableau / Looker

Fazit

Bei GitHub Copilot Enterprise geht es im Kern darum, deine Infrastruktur für KI-fähigen Code aufzubauen. Spaces liefern den Organisationskontext, der Copilot in realen Engineering-Umgebungen nützlicher macht. Die Usage Metrics API liefert die Telemetrie, um zu verstehen, ob die Adoption funktioniert.

Die Organisationen mit den stärksten Ergebnissen durch Copilot Enterprise zeigen ein gemeinsames Muster:

• Sie kuratieren internen Kontext sorgfältig
• Sie überwachen die Adoption kontinuierlich
• Sie nehmen Copilot-Governance ernst
• Sie messen Ergebnisse statt Produktivitätsgewinne anzunehmen

Diese Haltung ist weit wichtiger, als nur Lizenzen zu vergeben.

Wenn du deine Copilot- und KI-Kompetenzen vertiefen willst, empfehle ich unseren Kurs Software Development with GitHub Copilot oder den kompletten Lernpfad AI for Software Engineering.