Michael JohnsonSeit dem 3. November 2026 können Administratoren von Organisationen und Unternehmen die Nutzung eigener Schlüssel und unternehmenseigener Modelle in GitHub-Copilot-Berichten getrennt einsehen. Das Update der Copilot Usage Metrics API hilft dabei, Anfragen an von GitHub gehostete Modelle von der Nutzung per BYOK – „Bring your own key“ – oder eines von der Organisation konfigurierten Modells zu unterscheiden.
Für Unternehmen ist das eine praktische Änderung bei der Erfassung: Ausgaben für externe Anbieter und lokale Ausführungen lassen sich von der Nutzung der von GitHub betriebenen Modelle trennen. Führungskräfte und Administratoren erhalten dadurch einen aussagekräftigeren Überblick darüber, welche KI-Nutzungsarten in den Teams zum Einsatz kommen. GitHub zufolge weisen die neuen Felder BYOK gesondert aus den bereits vorhandenen Gesamtwerten aus, ohne die Zähler selbst zu verändern.
Welche Szenarien die API getrennt ausweist
GitHub unterscheidet zwei BYOK-Fälle. Beim lokalen BYOK richtet der Entwickler einen eigenen Schlüssel oder ein lokales Modell in Copilot CLI oder der GitHub-Copilot-App ein; die Anfrage geht direkt an den Anbieter oder den lokalen Server. Für solche Anfragen wurden das Nutzerfeld used_local_byok, die aggregierten Werte totals_by_local_byok und Zähler für aktive Nutzer mit lokalem BYOK ergänzt.
GitHub nennt Ollama, Foundry Local, LM Studio und llama-server als Beispiele für lokale Modelle und Tools. Die neuen Detailfelder für lokales BYOK gelten für Copilot CLI und die Copilot-App: Sie schlüsseln Sitzungen, Anfragen, Prompts und Tokens nach BYOK-Typ und Nutzungsschnittstelle auf, sofern der Anbieter die entsprechenden Daten übermittelt. Die Nutzung von lokalem BYOK wird nicht nach Modellnamen aufgeschlüsselt. Der Bericht zeigt daher, ob und in welchem Umfang eine solche Aktivität stattfindet, aber nicht, welches konkrete lokale Modell verwendet wird.
Das zweite Szenario ist ein unternehmenseigenes benutzerdefiniertes Modell, das ein Administrator in den Organisations- oder Unternehmenseinstellungen festlegt und dessen Anfragen über GitHub an den Anbieter weitergeleitet werden. Dafür hat GitHub das boolesche Feld is_custom_enterprise_model zu den Modelleinträgen in totals_by_client hinzugefügt. Da diese Anfragen serverseitig erfasst werden, deckt das Feld verschiedene Clients ab, einschließlich IDEs.
Was sich bei der Arbeit mit Berichten ändert
Bisher konnte die Nutzung von BYOK mit den Kennzahlen gehosteter Copilot-Modelle vermischt werden, besonders wenn Modelle ähnliche Namen hatten. Mit den neuen Feldern lassen sich diese Kategorien bei der Prüfung interner Richtlinien und der Nutzungsanalyse trennen. GitHub zufolge sind die Daten für Berichte über einen und 28 Tage verfügbar – sowohl auf Nutzerebene als auch in Organisations- oder Unternehmensaggregaten.
Administratoren sollten zunächst klären, welche Frage der Bericht beantworten soll: Wer nutzt einen eigenen Schlüssel, welcher Anteil der Anfragen geht an lokale Modelle und wie wirkt sich das auf die Kostenschätzung aus? Anschließend lassen sich die neuen Felder mit den bestehenden Kennzahlen und internen BYOK-Richtlinien abgleichen. Das bietet eine konkretere Grundlage für Gespräche über die Modellauswahl und die Abrechnung als ein allgemeiner Zähler der Copilot-Aktivität.
Der Zugriff auf die Kennzahlen hängt von der Rolle ab: Die API ist für Unternehmensinhaber, Abrechnungsmanager von Unternehmen, Organisationsinhaber und Nutzer mit der Berechtigung View Copilot Metrics vorgesehen. Außerdem muss die Richtlinie zur Nutzung von Copilot-Metriken aktiviert sein. Die Daten zeigen erfasste Aktivitäten, nicht die Qualität der Antworten oder die Eignung eines Modells für eine bestimmte Aufgabe.
Warum die beiden neuen Kennzahlen unterschiedlich genau sind
Beim lokalen BYOK gibt es eine konkrete Grenze der Erfassung: GitHub berechnet die entsprechenden Felder anhand clientseitiger Telemetrie. Ist die Telemetrie deaktiviert, liegt die Zahl solcher Anfragen unter dem tatsächlichen Wert; außerdem melden manche lokalen Anbieter keine Token-Anzahl. Die Daten eignen sich daher dazu, die Nutzung zu erkennen und ihre Größenordnung einzuschätzen, sind aber für einen präzisen finanziellen Abgleich unvollständig.
Unternehmenseigene benutzerdefinierte Modelle werden serverseitig erfasst und sind GitHub zufolge von dieser Einschränkung durch Telemetrie nicht betroffen. Dasselbe Modell kann in zwei getrennten Zeilen erscheinen, wenn es sowohl als gehostetes Copilot-Modell als auch als benutzerdefiniertes Unternehmensmodell genutzt wird. So werden unterschiedliche Nutzungskanäle nicht allein wegen eines identischen Namens zusammengeführt.
Hinzu kommt eine zeitliche Besonderheit: GitHub fügt das Feld is_custom_enterprise_model Berichten für Tage vor der Veröffentlichung des Updates nicht hinzu. Historische Daten lassen sich daher nicht automatisch mit den neuen Kategorien vergleichen. Für Trendanalysen sollte das Umstellungsdatum markiert und bei Vergleichen berücksichtigt werden, dass sich das Schema geändert hat.
Das Update hilft Organisationen, die Copilot-Nutzung mit eigenen oder lokalen Modellen genauer zu kategorisieren. Bei der Budgetierung von lokalem BYOK müssen weiterhin Lücken in der clientseitigen Telemetrie und Daten des Anbieters berücksichtigt werden; unternehmenseigene benutzerdefinierte Modelle erhalten dagegen ein eigenes serverseitiges Merkmal im Bericht.
