KI-News für Unternehmen · Stand 24. Oktober 2026

Sehen, welche Tools wirklich Copilot-Modelle nutzen.

GitHub hat die Nutzungsmetriken von Copilot innerhalb von zwei Tagen deutlich erweitert. Seit dem 23. Oktober 2026 zeigt die API, aus welchen Werkzeugen Copilot-Modelle aufgerufen werden, auch außerhalb der Entwicklungsumgebung. Seit dem 22. Oktober 2026 erscheinen die Namen eigener Skills, Agenten und MCP-Server. Für Unternehmen wird damit sichtbarer, wofür Copilot-Lizenzen tatsächlich genutzt werden.

LOL.MARKETING / INTELLIGENZ VERBINDEN

Auf den Punkt

Seit 23. Oktober 2026 enthält die Copilot-Nutzungsmetriken-API das neue Feld totals_by_client. Es zeigt je Werkzeug, etwa Claude Code, Codex, OpenCode, Zed, Copilot CLI, VS Code oder JetBrains, die Zahl der Modellanfragen, Sitzungen und Token, aufgeschlüsselt nach Modell. Seit 22. Oktober 2026 stehen in den Berichten außerdem die Namen eigener Skills, Agenten, MCP-Server, Slash-Befehle und Plugins. Zugriff haben Enterprise- und Organisations-Owner sowie Rollen mit der Berechtigung View Copilot Metrics.

01 / FIT

Geeignet, wenn

  • Unternehmen mit Copilot Business oder Copilot Enterprise, die Lizenzen, Werkzeuge und eigene Erweiterungen auf Basis tatsächlicher Nutzung steuern wollen.

02 / GRENZEN

Nicht die erste Wahl, wenn

  • Genaue Abrechnung oder Leistungsbewertung einzelner Personen: GitHub beschreibt die Werkzeugzuordnung als bestmögliche Gruppierung, und die Skill-Namen stammen aus Client-Telemetrie, die zu niedrig zählen kann.

Was ist neu?

Am 23. Oktober 2026 hat GitHub die Copilot-Nutzungsmetriken-API um das Feld totals_by_client erweitert. Es erfasst Modellnutzung aus Werkzeugen, die Copilot als Modellanbieter verwenden, darunter auch solche wie OpenCode, die bisher in den Berichten fehlten. Das Feld steht in den 1-Tages- und 28-Tages-Berichten für Enterprise, Organisation und einzelne Nutzer zur Verfügung.

Der Hintergrund laut GitHub: Immer mehr Entwickler nutzen Copilot als Modellanbieter hinter Werkzeugen außerhalb der Entwicklungsumgebung. Diese senden oft keine Editor-Telemetrie und fehlten deshalb in totals_by_ide. Die neue Zählung erfolgt auf dem Server und schließt diese Lücke.

Welche Daten liefert totals_by_client?

Jeder Eintrag steht für ein Werkzeug. Unbekannte Werkzeuge werden unter other zusammengefasst. GitHub nennt als Beispiele opencode, claude_code, codex, zed, copilot_cli, github_app, cloud_agent, code_review, vscode und jetbrains.

  • request_count: Zahl der erfolgreichen Modellanfragen, nicht der Prompts
  • session_count: Zahl der unterschiedlichen Sitzungen
  • token_usage: Prompt- und Ausgabe-Token sowie durchschnittliche Token je Anfrage
  • totals_by_model: dieselben Werte je Modell, mit model_selection_mode (user_selected, auto, product_selected)

Was zeigen die Berichte zu eigenen Erweiterungen?

Seit dem 22. Oktober 2026 zeigen die Listen totals_by_skill, totals_by_custom_agent, totals_by_mcp, totals_by_slash_cmd und totals_by_plugin den konfigurierten Namen eigener Einträge statt other oder custom. Jede Liste enthält laut GitHub jetzt bis zu 25 Einträge statt fünf; der Rest wird unter other zusammengefasst.

Die Namen kommen aus Copilot CLI, der GitHub-Copilot-App, ACP-Integrationen wie JetBrains und dem Copilot SDK. Nötig sind Copilot CLI ab Version 1.0.97 beziehungsweise Copilot SDK ab Version 1.0.21. Aus dem eingebauten Chat einer IDE werden keine Namen gemeldet. Namen erscheinen erst für Berichtstage nach dem Release.

Wo liegen die Grenzen der Zahlen?

GitHub nennt mehrere Einschränkungen. request_count zählt Modellaufrufe; ein Prompt kann mehrere Aufrufe auslösen, deshalb lässt sich das Feld nicht direkt mit Prompt-Zahlen vergleichen. Werkzeuge werden über die mitgesendete Integrations-ID erkannt, das ist eine bestmögliche Gruppierung und keine geprüfte Identität. Bei Code Review und Cloud Agent wählt das Produkt das Modell, die Code-Review-Modelle erscheinen als unknown.

Die Namen eigener Erweiterungen stammen aus Client-Telemetrie und können laut GitHub zu niedrig ausfallen, etwa bei veralteten Clients oder blockierter Telemetrie. GitHub empfiehlt, sie für Trends und Verbreitung zu nutzen, nicht für exakte Abrechnung. Außerdem sollten Namen vor einer Weitergabe von Berichten nach außen geprüft werden.

Warum ist das für Unternehmen wichtig?

Viele Teams nutzen inzwischen mehrere KI-Werkzeuge parallel. Wenn Copilot im Hintergrund als Modellanbieter für Claude Code, Codex oder OpenCode dient, war diese Nutzung bisher kaum sichtbar. Mit totals_by_client können Unternehmen erkennen, welche Werkzeuge Anfragen und Token treiben, und Entscheidungen über unterstützte Tools und Richtlinien auf tatsächliche Nutzung stützen, wie GitHub es beschreibt.

Für Betriebsrat und Datenschutz gilt: Die Berichte gibt es auch je Nutzer. Klären Sie vorab, wer die Daten sehen darf und wofür sie verwendet werden. Leistungskontrolle einzelner Personen ist ein sensibles Thema und sollte in der KI-Richtlinie geregelt sein.

Was sollten Admins jetzt tun?

Prüfen Sie, ob die Richtlinie für Copilot-Nutzungsmetriken aktiviert ist, denn ohne sie gibt es keine Berichte. Vergeben Sie die Berechtigung View Copilot Metrics gezielt über eigene Rollen. Werten Sie totals_by_client über 28 Tage aus und gleichen Sie die Liste mit den freigegebenen Werkzeugen ab. Aktualisieren Sie Copilot CLI und SDK, damit Namen eigener Skills und MCP-Server erscheinen.

Ändert sich an bestehenden Feldern etwas? Nein, die Änderung ist laut GitHub additiv, und totals_by_client ist ein leeres Array, wenn es nichts zu melden gibt. Der kostenlose KI-Systemcheck hilft, Werkzeuge, Freigaben und Kennzahlen im Team zu ordnen. Die Hinweise hier sind Vorschläge, keine Kundenergebnisse.

Nachvollziehbar bleiben

Primärquellen

Nächster sinnvoller Schritt

Wissen Sie, welche KI-Tools Ihr Team wirklich nutzt?

In acht Schritten vom allgemeinen KI-Interesse zu einer klareren Entscheidung für Ihren Betrieb.

KI-Systemcheck starten
KostenlosAnbieterneutralKeine Zugangsdaten