GitHub erweitert die Copilot Usage Metrics API um Aktivitätsdaten für Skills, Custom Agents, MCP-Server, Slash Commands und Plugins in der Copilot CLI. Unternehmen können damit erkennen, welche Erweiterungen am häufigsten verwendet werden und wie viele unterschiedliche Elemente im Einsatz sind. Für laufende KI-Rollouts ist das wertvoll – solange Aktivität nicht vorschnell mit Produktivität, Qualität oder wirtschaftlichem Nutzen gleichgesetzt wird.
Bestätigt ist: Die neuen Felder erscheinen in Tagesberichten für Enterprise und Organisationen, jeweils aggregiert und pro Nutzer, außerdem in nutzerbezogenen 28-Tage-Berichten sowie in den day_totals aggregierter 28-Tage-Berichte. Je Kategorie listet GitHub bis zu fünf Elemente mit der meisten aufgezeichneten Aktivität. Separate Distinct-Felder zählen, wie viele verschiedene Elemente verwendet wurden, einschließlich Einträgen außerhalb dieser Top fünf.
Welche Fragen die neuen Metriken beantworten
Die Top-Listen beantworten eine Priorisierungsfrage: Welche Skills, Agenten, MCP-Server, Slash Commands oder Plugins erzeugen die meiste aufgezeichnete Aktivität? Jeder Eintrag enthält einen interaction_count. Dessen Bedeutung unterscheidet sich jedoch nach Kategorie: Bei Skills und Slash Commands werden Aufrufe gezählt, bei Custom Agents Starts und bei MCP-Servern Verbindungs- oder Wiederverbindungsversuche.
Die Distinct-Felder beantworten eine zweite Frage: Wie breit ist das Werkzeugportfolio tatsächlich? In einem Nutzerbericht zählt jedes von dieser Person verwendete Element einmal. In einem aggregierten Bericht zählt ein Element einmal für die gesamte Organisation oder das Enterprise – nicht einmal je Nutzer. Steigt dieser Wert, wächst die Vielfalt der genutzten Anpassungen. Ob diese Vielfalt hilfreich oder unkontrollierte Fragmentierung ist, lässt sich daraus allein nicht ableiten.
- Top-Aktivität zeigt Konzentration: Wenige Erweiterungen können einen großen Teil der Nutzung tragen.
- Distinct Counts zeigen Vielfalt: Sie umfassen auch Elemente, die nicht in den Top fünf erscheinen.
- Tagesdaten eignen sich für Einführungseffekte und technische Auffälligkeiten.
- 28-Tage-Daten glätten einzelne Spitzen und helfen bei der Bewertung wiederkehrender Nutzung.
- Nutzerberichte unterstützen gezieltes Enablement, während aggregierte Berichte Portfolio- und Governance-Fragen adressieren.
Drei Messfallen, die Unternehmen vermeiden sollten
1. MCP-Verbindungen sind keine Toolaufrufe
Bei MCP-Servern steigt interaction_count nur, wenn Copilot CLI eine Verbindung oder Wiederverbindung versucht. Erfolgreiche und fehlgeschlagene Versuche werden beide gezählt. Mehrere Toolaufrufe innerhalb derselben Verbindung erhöhen den Wert nicht. Eine hohe Zahl kann deshalb auf breite Nutzung, instabile Verbindungen oder häufige neue Sitzungen hindeuten. Ohne technische Kontextdaten ist keine eindeutige Bewertung möglich.
2. Plugin- und Skill-Zahlen dürfen nicht addiert werden
Plugin-Metriken erfassen nur Skill-Aufrufe, die zu einem Plugin gehören. Jede erfasste Plugin-Interaktion erscheint damit auch in den Skill-Gesamtwerten. GitHub weist ausdrücklich darauf hin, dass Plugin-Werte eine Teilmenge der Skill-Werte sind. Wer beide Summen addiert, zählt Aktivität doppelt und überschätzt die Adoption.
3. Sammelkategorien begrenzen die Detailanalyse
GitHub zeigt Namen erkannter eigener Elemente. Kundendefinierte Namen werden zum Schutz der Privatsphäre nicht offengelegt: Skills, Custom Agents, MCP-Server und Plugins werden unter other zusammengefasst, eigene Slash Commands unter custom. Das schützt individuelle Konfigurationen, begrenzt aber die Frage, welche konkrete interne Automatisierung erfolgreich ist. Dafür braucht es ergänzende, intern verantwortete Telemetrie mit klaren Datenschutzregeln.
Ein Vier-Stufen-Modell für die Adoptionsmessung
1. Messzugriff und Datenqualität absichern
Prüfen Sie zuerst, ob die Copilot Usage Metrics Policy aktiviert ist und wer die Berechtigung View Copilot Metrics besitzt. Laut GitHub können unter anderem Enterprise Owner, Billing Manager, Organization Owner und entsprechend ausgestattete benutzerdefinierte Rollen auf Berichte zugreifen. Definieren Sie einen kleinen Empfängerkreis und dokumentieren Sie, wie nutzerbezogene Daten verwendet werden dürfen.
2. Ausgangslage statt Zielwert erfassen
Beobachten Sie zunächst einen vollständigen Zeitraum und trennen Sie Kategorien. Leere Arrays und Nullwerte bedeuten keine passende Aktivität; fehlende oder null gesetzte Felder können dagegen anzeigen, dass Anpassungsdaten nicht verfügbar sind. Diese Zustände dürfen in einem Dashboard nicht zusammengeführt werden, weil sonst technische Datenlücken wie Nichtnutzung aussehen.
3. Enablement-Hypothesen prüfen
Nutzen Sie Top- und Distinct-Werte, um konkrete Fragen zu formulieren: Ist ein bereitgestellter Skill unbekannt? Wird ein MCP-Server häufig neu verbunden, aber liefert wenig messbaren Prozessnutzen? Konzentriert sich die Nutzung auf wenige Spezialisten? Daraus lassen sich Trainings, bessere Dokumentation oder eine technische Stabilitätsprüfung ableiten. Die Metrik liefert den Hinweis, nicht bereits die Ursache.
4. Nutzung mit Ergebnissen verbinden
Ergänzen Sie die GitHub-Daten um Kennzahlen aus dem betroffenen Prozess: Durchlaufzeit, Fehlerrate, Review-Aufwand, erfolgreiche Automationsabschlüsse oder Supportbedarf. Vergleichen Sie Teams und Zeiträume nur, wenn Aufgaben, Rollen und Messbedingungen hinreichend ähnlich sind. Erst diese Verbindung erlaubt eine belastbare Aussage darüber, ob Investitionen in Skills, Agenten oder MCP-Integrationen Wert schaffen.
Entscheidungsrahmen für Portfolio und Betrieb
- Hohe Aktivität und nachweisbarer Nutzen: standardisieren, dokumentieren und verlässlich betreiben.
- Hohe Aktivität ohne Ergebnisverbesserung: Arbeitsablauf prüfen, Schulung verbessern oder Fehlanreize ausschließen.
- Geringe Aktivität bei wichtigem Anwendungsfall: Auffindbarkeit, Berechtigungen, Onboarding und technische Hürden untersuchen.
- Wachsende Vielfalt ohne Governance: Katalog, Eigentümer, Freigabekriterien und Lebenszyklus für Erweiterungen einführen.
- Viele MCP-Verbindungsversuche: Erfolg und Fehler getrennt beobachten, bevor Adoption oder Stabilität bewertet wird.
Für Geschäftsführer und IT-Leitung entsteht damit erstmals ein breiteres Bild der agentischen Copilot-CLI-Nutzung. Der größte Nutzen liegt nicht in einem Ranking einzelner Entwickler, sondern in der Steuerung des Portfolios: Welche Erweiterungen verdienen Betriebskapazität, wo fehlen Schulung und Standards, und welche Experimente können beendet werden?
Die neuen Felder sind ein guter Startpunkt für ein monatliches Adoptionsreview. Sie ersetzen jedoch keine Wirkungsmessung. Wer technische Aktivität, Nutzungsbreite, Prozessqualität und Kosten getrennt erhebt und erst danach zusammenführt, kann Investitionen in agentische Entwicklerwerkzeuge nachvollziehbar priorisieren – ohne aus Verbindungsversuchen oder Aufrufzahlen eine erfundene Produktivitätsgeschichte zu machen.