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

Was ist GitHub Copilot Enterprise?

GitHub Copilot Enterprise steht an der Spitze der Copilot-Angebotspalette von GitHub.

Im Vergleich zu GitHub Copilot Business oder Pro+ legt Enterprise den Schwerpunkt auf Governance, Organisationskontext und Messbarkeit. Es ist für Unternehmen mit großen Engineering-Umgebungen 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 Features machen aus Copilot mehr als nur „smarte Autovervollständigung“ – eher eine interne KI-Engineering-Plattform.

Unternehmen, die den größten Nutzen aus GitHub Copilot Enterprise ziehen, behandeln es als Schlüsselbaustein ihrer internen Infrastruktur. Sie konfigurieren den Organisationskontext sorgfältig, messen die Einführung kontinuierlich und passen Richtlinien auf Basis der Nutzungsdaten an – nicht auf Annahmen.

Für einen breiteren Blick auf das GitHub-Ökosystem empfehle ich unseren Leitfaden Introduction to GitHub Products.

So unterscheidet sich Enterprise von Business und Pro+

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

• Nutzungsmetriken auf Organisationsebene
• Erweiterte Governance-Kontrollen
• Unternehmensweite Richtlinienvererbung
• Größere Premium-Kontingente (1.000 statt 300 im Business-Tarif)
• Zusätzlicher Modellzugriff und -verwaltung

Enterprise erfordert GitHub Enterprise Cloud zusätzlich zum Copilot-Enterprise-Abo. Das verursacht zusätzliche Kosten pro Nutzer. Stelle daher sicher, dass deine Organisation tatsächlich 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 mit bereits ausgereiften GitHub-Umgebungen.

Typische Enterprise-Kunden sind:

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

Beachte, dass dies die Leistung von Copilot nicht automatisch verbessert. Diese Unterscheidung ist wichtig, weil viele Teams anfangs zu groß einkaufen. Sie setzen „Enterprise = besseres Copilot“ gleich, obwohl Enterprise vor allem Governance- und Messwerkzeuge hinzufügt.

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. Deinen internen API-Kanon, Architekturentscheidungen, Code-Konventionen, Deployment-Workflows oder Onboarding-Dokus versteht es jedoch nicht automatisch.

Spaces liefern einen kuratierten Organisationskontext, auf den Copilot in Unterhaltungen und bei der Codeassistenz zurückgreifen kann.

Ganz praktisch helfen Spaces Copilot, Fragen wie diese zu beantworten:

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

Was Spaces unterstützen

Spaces unterstützen mehr Organisationsinhalte 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 anders bei.

Code-Dateien helfen Copilot, Implementierungsmuster zu verstehen. Markdown liefert Architekturerklärungen und Onboarding-Hinweise. Pull Requests zeigen Review-Diskussionen und frühere Engineering-Entscheidungen. Diese Kombination gibt Copilot ein besseres Verständnis für die Entwicklungspraxis deiner Organisation.

Wichtig ist: Spaces sind nicht einfach nur Vektordatenbanken, die an GitHub angeflanscht sind. Sie beinhalten Freigabesteuerung und Governance-Workflows, die für Enterprise-Umgebungen ausgelegt sind.

Das Ende der Knowledge Bases

GitHub hat das ältere Feature Copilot Knowledge Bases am 1. November 2025 abgekündigt.

Spaces haben Knowledge Bases ersetzt durch:

• Breitere Inhaltsunterstützung
• Bessere Freigabekontrollen
• Verbesserte Administration
• Flexiblere Verwaltung auf Organisationsebene

Du wirst weiterhin veraltete Dokus und Blogposts finden, die Knowledge Bases erwähnen. Sei bei älteren Tutorials vorsichtig, da sich während des Übergangs 2025 bis 2026 viele Endpoints und Workflows geändert haben.

Copilot Spaces erstellen und konfigurieren

Aus Administrationssicht lassen sich Copilot Spaces recht unkompliziert anlegen. Die Herausforderung liegt in der Verwaltung von Dutzenden oder Hunderten Spaces über Teams hinweg.

Die frühe Struktur bleibt meist lange bestehen. Ich habe gesehen, wie Organisationen unbeabsichtigt „Dokusprawl“ in Spaces erzeugen, weil anfangs keine Ownership-Regeln definiert wurden.

Jede Person kann einen Copilot Space erstellen, also probieren wir es in unserem persönlichen Repo aus. Auf Enterprise-Ebene sind die Schritte ähnlich, nur mit ein paar anderen Seiten.

Ein Space einrichten

Das Erstellen eines Space folgt im Grunde diesem Ablauf:

1. Navigiere zur Copilot-Spaces-Seite im Enterprise-Administrationsbereich
2. Erstelle einen neuen Space

3. Wähle Repositories und Inhaltsquellen, 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 die Freigabeeinstellungen festlegen

6. Prüfe, ob Copilot den Inhalt in Chats referenzieren kann

Hinweis für Enterprise-User: Deine Administratoren können 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 Unternehmens verwendet.

Nach dem Setup sollten Administratoren den Space mit praxisnahen Prompts testen.

Beispielsweise:

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 antwortet, liegt es meist an:

• Fehlenden Repositories
• Schwacher Dokumentationsqualität
• Falschen Berechtigungen
• Unzureichender Indexierungszeit

Teilen und Zugriffskontrollen

Spaces unterstützen zwei Haupt-Modelle der Sichtbarkeit:

• Individuelle Spaces
• Organisationsweite Spaces

Mitglieder einer Enterprise können ihre individuellen Spaces über die allgemeinen Enterprise-Einstellungen verwalten lassen. Enterprise-Admins können außerdem zentral Preview- und Feature-Verfügbarkeiten steuern. 

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

Ein häufiger Fehler ist Überzentralisierung. Ein einziger, gigantischer Unternehmens-Space wird schnell laut und erschwert Copilot die effektive Nutzung.

Spaces nach Team oder Domäne organisieren

Es gibt keine universell richtige Struktur.

Gängige Muster sind ein Space pro Team, ein Space pro Produktbereich oder geteilte Standard-Spaces. Jede Variante hat einen anderen Zuschnitt und nutzt die gleichen Einstellungen anders.

Ein Space pro Team

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

Beispiele:

• Plattform-Engineering
• Data Engineering
• Mobile-Entwicklung

Ein Space pro Produktbereich

Hilfreich für Organisationen, die sich eher nach Produkten als nach Abteilungen strukturieren.

Beispiele:

• Zahlungen
• Analytics
• Infrastruktur
• Kundenplattform

Geteilter Standards-Space

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

• Sicherheitsrichtlinien
• Code-Konventionen
• Deployment-Workflows
• Architekturstandards

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

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-Einführung gelingt. Das Management will Belege, dass die Investition Entwickler-Workflows verbessert – und nicht nur eine weitere Aboposition ist.

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

Copilot Usage Metrics Dashboard example from github.blog

Was die API misst

Die Usage Metrics API stellt mehrere Kategorien operativer Telemetrie bereit.

Typische Metriken sind:

• Aktive Nutzer
• Vorgeschlagene vs. akzeptierte Codezeilen
• IDE-Nutzungsmuster
• Modellnutzung
• Agent-Interaktionen
• Sprachaufschlüsselungen

So erhalten Organisationen ein deutlich differenzierteres Bild als über einfache Platzanzahlen.

Ein Team mit 100 zugewiesenen Plätzen, aber nur 15 aktiven Nutzern hat ein ganz anderes Einführungsprofil 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 Übergang 2025 bis 2026 eingestellt; final ab April 2026.

Dazu zählten:

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

Die neueren Usage-Metrics-Endpoints, verfügbar seit Februar 2026, haben diese Reportings zu einem einheitlicheren Modell konsolidiert – inklusive Versionierung für den Fall von Breaking Changes.

Das ist wichtig, weil viele ältere Blogposts und GitHub-Beispiele noch auf veraltete Endpoints verweisen. Prüfe bei der Arbeit mit der Usage Metrics API immer die Doku gegen die neuesten API-Referenzen von GitHub, 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

Für Endpoints der GitHub Copilot Usage Metrics sind in der Regel einige Berechtigungen für dein Personal Access Token (PAT) nötig. Das geht entweder über das klassische PAT oder ein fein granuliertes PAT.

• Für klassische PATs muss dir deine Enterprise-Admin folgende Berechtigungen erteilen: manage_billing:copilot und read:org. 

• Für fein granulierte Zugriffstokens musst du sicherstellen, dass du das GitHub-App-User-Access-Token oder Installation-Access-Token mit der Berechtigung Enterprise Copilot metrics enterprise permissions (read) nutzt.

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

Endpoints auf Organisationsebene

Die zwei häufigsten 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 kurzfristige Trendanalysen. Historische Daten sind rückwirkend bis zum 10. Oktober 2025 verfügbar und können bis zu ein Jahr ab heutigem Datum abgerufen werden.

Der folgende curl-Befehl ruft den Ein-Tages-Metrik-Endpoint auf und gibt als JSON Download-Links für die Nutzungsreports zurück. Du musst YOUR_TOKEN für die Bearer-Auth einsetzen und einen 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 laufen kurz nach dem Abruf ab. Dein Workflow muss die Download-URL holen und die Datei direkt im selben Lauf laden – ein späteres Verwenden der URLs ist nicht möglich.

Die Antwort kann nur download_links und report_day enthalten, aber so sieht das vollständige potenzielle Schema aus:

{
  "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 Einführungsmuster und längerfristige Nutzungsänderungen zu erkennen. Die Befehle sind sehr ähnlich; du nutzt lediglich den 28-Tage-Endpoint.

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

Die Antwort ist ähnlich, enthält aber zusätzlich response_start_day und response_end_day.

Struktur der Reports auf Organisationsebene

Die JSON-Reports für den Ein-Tages- und 28-Tage-Report auf Organisationsebene könnten 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, bekommst du so einen Überblick über die Nutzer in einer Organisation, ihre Teams und Team-Tags. 

Endpoints auf Nutzerebene

Reports auf Nutzerebene liefern granularere Einblicke zur Einführung. So verstehst du auf hoher Ebene, wie einzelne Personen Copilot verwenden.

Häufige Endpoints sind:

• users-1-day

• users-28-day

• user-teams-1-day

Diese Reports helfen Administratoren, Folgendes zu erkennen:

• Sehr aktive Nutzer
• Teams mit niedriger Einführung
• Weiterbildungsbedarfe
• Nutzungstrends auf Abteilungsebene

Die Anfragen ähneln stark denen auf Organisationsebene für einen Tag bzw. 28 Tage; sie zeigen lediglich auf andere Endpoints.

Ein-Tages-Report auf Nutzerebene

Beispielaufruf für users-1-day:

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 für users-28-day:

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 auf User-Teams-Ebene

Es gibt auch den Endpoint user-teams-1-day, der Nutzer ihren Teamzugehörigkeiten zuordnet. Er enthält selbst keine Nutzungsmetriken und dient als Join-Key, wenn du Nutzerdaten nach Teams aggregieren willst.

Struktur der Reports auf Nutzerebene

Das Detailniveau dieser Reports ist deutlich höher, da sie auf die Nutzung einzelner Nutzer 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 zur Team-Einführung. Akzeptanzraten und Nutzungszahlen sind operative Signale, keine Messungen der Entwicklerqualität.

Für die vollständigen potenziellen Metriken, die du sehen könntest, besuche die GitHub usage metrics data documentation mit den aktuellsten Messgrößen.

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

Einen Copilot-Reporting-Workflow aufbauen

Das manuelle Aufrufen der API ist nützlich zum Experimentieren und zum Verständnis des Schemas. Für echte Wirkung ist ein automatisierter Workflow besser.

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

Wichtige Metriken zum Nachweis des ROI

Nicht jede Copilot-Metrik ist gleich wichtig. Besonders hilfreich sind meist:

• Wachstum aktiver Nutzer
• Trends bei den Akzeptanzraten
• Vorgeschlagener versus übernommener Code
• Verbesserungen der PR-Durchlaufzeiten
• Häufigkeit der IDE-Nutzung

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 gibt es die Usage Metrics API. Ein Backend-Infrastrukturteam interagiert mit Copilot anders als ein Frontend-Prototyping-Team.

Vom Rohdaten-Feed zum Team-Dashboard

Ein schlanker Reporting-Workflow sieht oft so aus:

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

Der konkrete Stack ist weniger wichtig als die Konsequenz in der Umsetzung.

Selbst ein einfacher Workflow mit geplanten Python-Skripten und CSV-Exports kann wertvolle operative Transparenz schaffen.

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 Einführung gelingt.

Die Organisationen mit den stärksten Ergebnissen folgen meist einem Muster:

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

Diese Haltung zählt weit mehr, als nur Plätze zuzuweisen.

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.