GitHub ist der Ansicht, dass die Effizienz von Programmieragenten anhand der Tokenzahl eines einzelnen Aufrufs zu messen, zu einem irreführenden Ergebnis führen kann. Eine kürzere Ausgabe kann das Modell dazu zwingen, einen Befehl erneut auszuführen oder entfernte Informationen anzufordern, wodurch auf Ebene der gesamten Aufgabe die Zahl der Durchläufe, die benötigte Zeit und die Kosten steigen. Daher bewertete das Unternehmen die Verbesserungen von GitHub Copilot anhand des endgültigen Ergebnisses der Aufgabe und nicht anhand des Umfangs der Antwort eines einzelnen Tools.
In einem am 2. September 2026 von Eric Christensen und Nabaless Klesius veröffentlichten Blogbeitrag erläuterte GitHub vier Änderungen, die nach eigenen Angaben zunächst durch Offline-Tests anhand von Benchmarks zur Bewertung agentischer Programmieraufgaben entwickelt und anschließend vor ihrer Einführung durch kontrollierte Nutzerexperimente überprüft wurden. Mehrere Copilot-Produkte, darunter die GitHub-Copilot-App und die Codeüberprüfung, verwenden dieselbe Infrastruktur, während die im Blogbeitrag enthaltenen Beispiele aus GitHub Copilot CLI stammen.
Warum reicht eine kürzere Antwort nicht aus?
GitHub testete die Auswirkungen des Tools RTK, also des Rust Token Killer, das Shell-Ausgaben komprimiert, bevor sie dem Agenten angezeigt werden. In den verwendeten Testkonfigurationen führte das Entfernen einiger wichtiger Textstellen dazu, dass die ursprünglichen Ausgaben erneut geöffnet oder die Befehle erneut ausgeführt wurden. Dadurch verringerte sich zwar die Ausgabegröße des Tools lokal, doch die Aufgabe benötigte im Durchschnitt mehr Token und mehr Zeit.
Das Unternehmen betont, dass dieses Ergebnis für die getestete Integration und die getesteten Workloads gilt und kein Urteil über alle RTK-Konfigurationen oder alle Methoden zur Ausgabekomprimierung darstellt. Die praktische Lehre besteht darin, dass der Bewertungsmaßstab von der Nutzeranfrage bis zum endgültigen Ergebnis reichen und Wiederherstellungs- sowie Nacharbeitsdurchläufe berücksichtigen sollte.
Selektive Ausgabekomprimierung
GitHubs Lösung bestand darin, wiederkehrendes Rauschen zu komprimieren und zugleich die Informationen zu bewahren, die der Agent benötigt. Betriebsanalysen zeigten, dass Installations-, Build-, Test- und Lint-Ausgaben häufig eine große Menge an Wiederholungen enthalten, während codeähnliche Ausgaben und Ergebnisse beliebiger Befehle notwendige Informationen enthalten können.
Die eingeführte Version verfolgte eine Strategie mit drei Punkten:
- Codeähnliche Ausgaben und Ergebnisse beliebiger Befehle unverändert beibehalten, darunter Befehle wie cat, git diff, git show und beliebige Skripte.
- Suchergebnisse wie grep-Ergebnisse und Dateilisten neu strukturieren, ohne ein Ergebnis zu entfernen.
- Installations-, Build-, Test- und Fortschrittsausgaben nur dann komprimieren, wenn die Einsparung erheblich ist.
Copilot behielt außerdem einen direkten Weg zum Abruf der vollständigen ursprünglichen Ausgabe bei. GitHub verfolgte die Nutzung dieses Weges weiterhin als Sicherheitsmechanismus und als Indikator dafür, dass die Komprimierung nützliche Informationen entfernt hatte. Bei den Offline-Aufgaben, für die die Komprimierung aktiviert war, stellte das Unternehmen keinen statistisch signifikanten Rückgang des Aufgabenerfolgs fest. Gleichzeitig senkte der Online-Versuch die durchschnittlichen Kosten geringfügig, ohne wesentliche Einbußen bei den beobachteten Qualitätskennzahlen.
Entfernung unnötiger Formatierungen
Eine der deutlichsten Einsparungen erzielte GitHub mit dem Tool view, das dem Modell Dateiinhalte anzeigt. Das Tool fügte jeder Zeile eine Zeilennummer hinzu, obwohl die aktuellen Bearbeitungswerkzeuge auf dem Abgleich des umgebenden Codes basieren und diese Nummern im üblichen Arbeitsablauf nicht verwenden. Daher entfernte das Unternehmen diese Präfixe aus Dateiansichten, behielt Zeilennummern jedoch in Diffs und kurzen Ausschnitten bei, wo sie nützlich sind.
Die Änderung senkte die Inferenzkosten des Modells in Offline-Benchmarks für agentische Programmieraufgaben um etwa 5 %. Die Erfolgsraten blieben innerhalb der erwarteten Schwankungsbreite, und die Zahl der Bearbeitungsfehler stieg nicht. In einem Online-Experiment mit Nutzern von Copilot CLI sanken die durchschnittlichen täglichen Inferenzkosten pro Nutzer um etwa 3 %, ohne wesentliche Rückgänge bei den von GitHub gemessenen Qualitäts- oder Zufriedenheitskennzahlen.
Anweisungen kürzen, ohne das Verhalten zu verändern
Die Anweisungen für das Tool task waren durch Toolbeschreibungen, Schemata, Agentendefinitionen und Systemanweisungen angewachsen. GitHub verwendete eine Schleife zur automatischen Optimierung der Anweisungen, verkürzte den Text um etwa die Hälfte und testete anschließend die Verhaltensweisen, die beibehalten werden sollten.
Der erste Online-Versuch offenbarte jedoch ein Problem, das in den Offline-Bewertungen nicht aufgetreten war: Hinweise zu vorsichtiger Parallelisierung wurden in eine strikte Planungsrichtlinie umgewandelt, sodass unabhängige Subagenten nacheinander arbeiteten. GitHub stoppte den Versuch, fügte einen Regressionstest für dieses Verhalten hinzu und ersetzte die Liste mit Erlaubnissen und Verboten durch einen einzigen Satz: „Unabhängige Agenten können parallel arbeiten; berücksichtige Nebenwirkungen.“
Die endgültige Fassung entfernte pro Runde etwa 1300 Token aus den Anweisungen des Task-Tools. Dies entsprach einem Rückgang der gesamten Anweisungstoken pro Sitzung um etwa 1,8 % und der normalisierten Kosten pro Aktivitätsstunde um 2,9 %, ohne dass in den gemessenen Bewertungen ein Qualitätsrückgang festgestellt wurde.
Unnötige Abrufdurchläufe vermeiden
Agenten führen manchmal unabhängige Arbeiten im Hintergrund aus, etwa einen langen Shell-Befehl parallel zu einer Untersuchung durch einen Subagenten. Zuvor wurden Benachrichtigungen über den Abschluss dieser Arbeiten ohne das eigentliche Ergebnis übermittelt, sodass der Agent einen zusätzlichen Aufruf benötigte, um Ausgaben abzurufen, die Copilot bereits erhalten hatte. Nun sammelt das System geeignete Abschlussbenachrichtigungen und sendet die abgeschlossenen Ergebnisse im bestehenden Format für Tool-Ergebnisse.
In dem Beispiel, das einen Shell-Befehl und einen Subagenten kombiniert, erforderte der Abschluss der Arbeit zuvor vier Modellaufrufe: zwei Aufrufe zum Anfordern der Ergebnisse und zwei zu deren Verarbeitung. Nach der Änderung treffen beide Ergebnisse gemeinsam in einem einzigen Aufruf zur Verarbeitung ein. Dadurch sank die durchschnittliche tokenbezogene Nutzung, gemessen in AI-Credits, um etwa 2,3 %.
Was ändert sich in der Praxis?
GitHubs Experiment liefert Programmieragenten-Entwicklern eine wichtige Grundlage: Die sicherste Optimierung besteht nicht darin, möglichst viel Text zu entfernen, sondern Arbeit zu beseitigen, die das Modell überhaupt nicht benötigt. Dazu gehören nicht verwendete Formatierungen, Warte- und Abrufdurchläufe, die das System selbst erledigen kann, sowie Wiederholungen, die sich komprimieren lassen, sofern ein Wiederherstellungspfad bereitsteht.
Andererseits lässt sich nicht jedes Ergebnis außerhalb der Testumgebung verallgemeinern. Die Einschränkung der Anweisungen für Dateitools führte trotz ihres Erfolgs bei der Codeüberprüfung in einem Copilot-CLI-Experiment zu höheren Kosten, weshalb GitHub sie nicht eingeführt hat. Auch die Komprimierung von git diff wurde entfernt, nachdem die Benchmarks gezeigt hatten, dass die Agenten die ursprüngliche Ausgabe erneut öffneten, um die gelöschten Informationen wiederherzustellen.
Die Schlussfolgerung des Beitrags lautet, dass Änderungen auf Ebene der Aufgabe, des Workflows und des Produkts, in dem sie eingesetzt werden, anhand von Offline-Benchmarks, Online-Experimenten und klaren Verhaltenstests gemessen werden müssen. Die Auswirkungen dieser Verbesserungen auf einen einzelnen Nutzer hängen dagegen weiterhin von der Art der Aufgaben, den Tools und deren Ausgaben ab und lassen sich nicht allein aus einer lokalen Verringerung der Tokenzahl ableiten.