GitHub trennt die Aktivität externer Agent Apps in der Copilot Usage Metrics API erstmals pro Agent auf. Für Organisationen, die Claude, Codex und Copilot parallel in GitHub einsetzen, wird damit aus einer Sammelmetrik ein Ansatzpunkt für belastbares Portfolio-Reporting.
Was neu ist
In den 1- und 28-Tage-Reports für Enterprise, Organisation und Nutzer kann nun das optionale Array totals_by_3rd_party_agent erscheinen. Darin steht je erkannter Agent App ein Eintrag. GitHub nennt ausdrücklich Claude und Codex als Beispiele für Partner-Agenten in GitHub-Workflows.
totals_by_3rd_party_agent[]
├── agent_id # stabiler Join-Key
├── agent_name # nur Anzeigename
├── user_initiated_interaction_count # gestartete Agent-Jobs
└── session_count # nur Enterprise/OrganisationDas entscheidende Detail ist agent_id: Der Anzeigename kann sich ändern, für Zeitreihen und Kostenstellen-Zuordnung soll deshalb der stabile Identifier verwendet werden. session_count liefert GitHub nur in den aggregierten Enterprise- und Organisationsreports, nicht in den per-user-Varianten.
Warum das operativ relevant ist
Bislang war Agentenarbeit in den Nutzungsdaten im Wesentlichen ein gemeinsamer Block. Das erschwert zwei inzwischen normale Fragen: Welche Agenten werden tatsächlich gestartet? Und verschiebt sich Nutzung zwischen ihnen?
- Portfolio-Governance: Teams können Rollouts und Freigaben pro Agent statt nur für „Copilot-Nutzung“ verfolgen.
- Saubere Zeitreihen: Der stabile Identifier verhindert, dass eine Umbenennung künstlich einen neuen Agenten erzeugt.
- Richtige KPI-Interpretation: Das verschachtelte
user_initiated_interaction_countzählt gestartete Agent-App-Jobs. Es ist nicht derselbe Zähler wie das gleichnamige Top-Level-Feld für explizite Prompts aus anderer Telemetrie – beide Werte dürfen nicht addiert werden.
Die API schafft Sichtbarkeit über erkannte Agent Apps – aber noch kein vollständiges Agenten-Inventar.
Das Array wird ausgelassen, wenn für den Zeitraum keine Aktivität einer erkannten Agent App vorliegt. Für Governance ist das eine wichtige Grenze: Die Metrik zeigt den von GitHub erkannten Anteil, nicht automatisch jede denkbare Automatisierung im Unternehmen.
Was Teams jetzt tun sollten
- Den ETL-Job auf
totals_by_3rd_party_agenterweitern und nachagent_id, nicht nach Name gruppieren. - Agent-Job-Starts und Sessions getrennt von Prompt-, Request- und Outcome-Metriken auswerten.
- Die Agentenliste mit Freigabe-, Kosten- und Sicherheitsdaten abgleichen. Hohe Aktivität ist ein Signal für Prüfung, kein Produktivitätsbeweis.
Einordnung: GitHub liefert damit keine ROI-Metrik. Aber es beseitigt eine operative Blindstelle: In einem Multi-Agent-Stack lässt sich erstmals nachvollziehbar trennen, welcher Agent überhaupt Arbeit ausführt.
Leave a Reply