GitHub: Optimierung agentischer Workflows erzielt Token-Einsparungen von 19 % bis 62 %

Das GitHub-Engineering-Team veröffentlichte am 7. Mai 2026 eine Analyse ihrer eigenen Produktions-Agentenworkflows mit konkreten Zahlen zu Token-Verlusten und Optimierungsmaßnahmen. Der Beitrag ist ein seltenes Beispiel transparenter Kostenberichterstattung und hilft Teams, die ähnliche Systeme aufbauen.

Drei Hauptquellen der Token-Verschwendung

Erstens unnötige MCP-Tool-Schemata. Der volle GitHub-MCP-Server mit 40 Tools fügt pro Zug 10–15 KB Kontext hinzu, doch die meisten Workflows nutzen nur einige wenige Tools. Durch das Entfernen nicht genutzter Tools aus der MCP-Konfiguration verringerte sich die Kontextgröße pro Aufruf um 8–12 KB, was pro Lauf Tausende von Tokens einspart. MCP (Model Context Protocol) ist der Standard, über den Tools ihre Schemata dem Sprachmodell bereitstellen.

Zweitens deterministischer Datenabruf. Viele Agentenschritte sind Lesevorgänge, die kein Schlussfolgern erfordern — etwa das Abrufen von Issue-Metadaten. Durch das Verlagern solcher Abrufe in einen Vor-Agenten-CLI-Schritt, bevor das Modell aufgerufen wird, verlassen diese Aufrufe die LLM-Reasoning-Schleife vollständig.

Drittens falsch konfigurierte Regeln. Ein einzeiliger Fehler in der Bash-Allowlist löste eine 64-Schritt-Fallback-Schleife aus, in der der Workflow manuell die Compiler-Ausgabe rekonstruierte, anstatt das entsprechende Tool aufzurufen.

Konkrete Einsparungen pro Workflow

Fünf optimierte Workflows erzielten folgende Ergebnisse: Auto-Triage Issues Reduzierung 62 % (über 109 Läufe), Security Guard 43 %, Smoke Claude 59 %, Daily Compiler Quality 19 %, Community Attribution 37 %. Allein die Optimierung von Auto-Triage sparte etwa 7,8 Millionen Effective Tokens im Beobachtungszeitraum.

Was ist die Effective-Tokens-Metrik?

GitHub entwickelte die Formel ET = m × (1,0 × I + 0,1 × C + 4,0 × O) zur Normalisierung von Kosten über verschiedene Modellstufen hinweg. I sind Input-Tokens, C Cache-Read-Tokens, O Output-Tokens, m ein Modell-Multiplikator. Output-Tokens haben 4-faches Gewicht als teuerster Typ, während Cache-Read-Tokens nur 0,1× tragen. Die Metrik ermöglicht den direkten Vergleich von Workflows, die verschiedene Modelle und unterschiedliche Caching-Muster verwenden — das Team muss die Dollarkosten nicht separat pro Modell verfolgen.