Weniger Token sind nicht billiger: Coding-Agenten verschwenden Arbeit, nicht Token

Seit Coding-Agenten durchgestartet sind, starren Entwickler auf eine einzige Zahl: Token. Wie viele hat das Modell erzeugt, wie viele hat ein Tool zurückgegeben, wie groß ist der Kontext, wie viele hat der Agent verbraucht? Die Logik wirkt wasserdicht. Weniger Token sollten eine kleinere Rechnung bedeuten.

GitHubs Analyse des Copilot Coding Agent zeigt, warum diese Annahme riskant ist. Wer jede Tool-Antwort kürzt, kann die gesamte Aufgabe verteuern, wenn im gekürzten Text etwas Wichtiges stand. Der Agent führt dann Befehle erneut aus, gräbt die ursprüngliche Ausgabe wieder hervor, braucht zusätzliche Denkschritte und schleppt einen größeren Kontext durch alles, was folgt.

Die billigste Interaktion ist also nicht automatisch die mit den wenigsten Token. Was Sie eigentlich wollen, ist die erledigte Softwareaufgabe mit möglichst wenig verschwendeter Arbeit, und das verändert, wie man die Leistung eines Agenten beurteilen sollte.

Die Falle der lokalen Optimierung

Angenommen, ein Agent führt einen Testbefehl aus:

npm test

Er gibt 50.000 Token aus. Das wirkt verschwenderisch, also schreiben Sie einen Wrapper, der die Ausgabe auf 2.000 eindampft. Auf dem Papier ein Gewinn: 48.000 Token weniger.

Nun nehmen wir an, in diesen 2.000 Token fehlt genau das, was der Agent brauchte. Er antwortet etwa so:

I need more information about the failing test.

Also führt er den Befehl erneut aus, durchsucht die gespeicherte Ausgabe, öffnet die Logdatei oder probiert einen engeren Befehl. Der Ablauf sieht dann so aus:

Original command
      ↓
Compressed output
      ↓
Missing information
      ↓
Agent searches again
      ↓
Command runs again
      ↓
More context
      ↓
More reasoning

Der einzelne Schritt wurde billiger, die Aufgabe teurer. GitHub stieß darauf, als es Wege testete, die Ausgaben von Copilot zu kürzen. In einem Experiment kürzte ein Tool namens RTK die Shell-Ausgabe, und die Agenten öffneten oder wiederholten Befehle häufig, sobald das fehlende Detail wichtig war. Das Ergebnis waren mehr Runden und im Schnitt mehr Token sowie längere Laufzeiten. Im Nachhinein klingt das selbstverständlich, und trotzdem übersieht man es leicht, wenn man die falsche Zahl optimiert.

Bewerten Sie die Aufgabe, nicht den Aufruf

Ein Agent soll eine Softwareaufgabe erledigen und nicht die Kosten einer einzelnen API-Anfrage minimieren. Der Abstand zwischen diesen Zielen ist größer, als er klingt. Vergleichen wir zwei Agenten. Agent A:

Task
↓
8 tool calls
↓
100K tokens
↓
Completed in 4 minutes

und Agent B:

Task
↓
15 tool calls
↓
80K tokens
↓
Completed in 9 minutes

Nur nach Token gewinnt B. Wer aber eine Engineering-Organisation leitet, sieht ein trüberes Bild. A war schneller fertig, brauchte vermutlich weniger Wiederholungen, hat womöglich weniger Rechenleistung verbraucht, vielleicht einen besseren Patch geliefert und die Wartezeit der Entwickler gering gehalten. Musste jemand B noch fünf Minuten länger beaufsichtigen, steigt der tatsächliche Preis von B weiter.

Deshalb argumentiert GitHub, dass Tokenzahlen pro Interaktion wenig über die Effizienz eines Agenten aussagen. Optimieren sollte man das Ergebnis der gesamten Aufgabe.

Ein Kostenmodell von Anfang bis Ende

Erfahrene Ingenieure kennen das aus anderen Bereichen. Wer eine Datenbankabfrage von 200 ms auf 100 ms drückt, scheint klar zu gewinnen. Löst die neue Abfrage aber drei zusätzliche Anfragen in einem anderen Dienst aus, kann das Gesamtsystem langsamer werden. Man optimiert das System, nicht eine einzelne Operation.

Für Agenten gilt dieselbe Regel. Ein nützliches Denkmodell für die Gesamtkosten:

Total agent cost =
model inference
+ tool execution
+ retries
+ repeated work
+ context growth
+ developer waiting
+ infrastructure

Und ein Muster, das häufig auftaucht:

smaller response
+
missing context
=
more recovery work

Deshalb sieht KI-Engineering immer mehr wie Systems Engineering aus.

Nicht jede Ausgabe ist gleich viel wert

Eine bemerkenswerte Erkenntnis: Die Informationsdichte von Befehlsausgaben schwankt stark. Repetitive Logs von Installation, Build, Tests und Fortschritt können voller Rauschen sein. Quellcodeähnliche Ausgaben und Ergebnisse beliebiger Befehle können dagegen genau das enthalten, was der Agent braucht. Statt einer Kompressionsregel für alles hat GitHub einen selektiven Ansatz gebaut. Konzeptionell funktioniert er so:

Command output
      │
      ▼
┌──────────────────────┐
│ What kind of output? │
└──────────┬───────────┘
           │
     ┌─────┼─────┐
     │     │     │
     ▼     ▼     ▼
 Source  Search  Noise
 output  results logs
     │     │     │
     ▼     ▼     ▼
  Keep   Reorganize Compress
  all     without   selectively
          losing
          content

Das ist besser als die plumpe Alternative:

if output.length > X:
    truncate()

Die grobe Regel optimiert eine Zahl. Die selektive optimiert die Fähigkeit des Agenten, weiterzuarbeiten.

Was git diff lehrt

Stellen Sie sich einen Agenten vor, der fünf Dateien bearbeitet hat und jetzt Folgendes ausführt:

git diff

Die Ausgabe ist lang. Ein naiver Kompressor würde sagen, sie sei groß, und sie schrumpfen. Der Diff kann aber genau das enthalten, was der Agent braucht, um zu beurteilen, ob seine Änderungen stimmen. GitHub berichtet, dass frühe Versionen seines Kompressors git diff tatsächlich eindampften und Benchmarks zeigten, wie Agenten die Originalausgabe erneut öffneten, um an die Informationen zu kommen. Also flog dieser Filter raus.

Das ist eine großartige, KI-spezifische Lektion: Man kann etwas nicht für nutzlos erklären, nur weil es groß ist. Manche großen Ausgaben sind wertvoller Kontext, manche winzigen wertlos. Die Tokenzahl kann sie nicht unterscheiden.

Eigene Tools entwerfen

Wenn Sie einen Coding-Agenten bauen, schreiben Sie vielleicht das hier:

const result = await exec(command);

gefolgt von einer harten Obergrenze:

return result.stdout.slice(0, 5000);

Das wirkt vernünftig, unterstellt aber stillschweigend, dass die ersten 5.000 Zeichen alles enthalten, was der Agent braucht. Klüger ist es, die Ausgabe zuerst zu klassifizieren. Der Anfang ist derselbe:

const result = await exec(command);

Dann wird nach Art der Ausgabe verzweigt:

const outputType = classifyOutput(result);switch (outputType) {
  case "source":
    return result.stdout;  case "search":
    return reorganize(result.stdout);  case "repetitive-log":
    return compress(result.stdout);  default:
    return result.stdout;
}

Selbst das braucht einen Notausgang, damit der Agent das Original zurückholen kann:

return {
  summary,
  compressedOutput,
  fullOutputAvailable: true
};

Der Agent bekommt eine kompakte Ansicht, und trotzdem ist nichts wirklich verschwunden. Für autonome Systeme ist das ein deutlich besseres Design.

Kompression sollte aufschieben, nicht löschen

Kompression sollte nicht bedeuten, Informationen zu löschen. Sie sollte bedeuten, sie aufzuschieben, bis sie gebraucht werden. Vergleichen Sie beide Ansätze. Schlechte Kompression sieht so aus:

Original output
       ↓
Throw away 90%
       ↓
Agent cannot recover it

Bessere Kompression hält den Rückweg offen:

Original output
       ↓
Create useful summary
       ↓
Agent continues
       ↓
Needs more detail?
       ↓
Retrieve original

Das kommt der Funktionsweise von Caching in gewöhnlicher Software näher. Der Agent braucht nicht alles sofort, darf aber den Zugriff auf nichts Wichtiges verlieren. Der von GitHub ausgelieferte Ansatz bietet nach dem Komprimieren einer Ausgabe einen direkten Wiederherstellungspfad.

Manchmal ist mehr Kontext billiger

Das klingt verkehrt herum. Entwickler haben jahrelang den Kontext verkleinert. Mehr Kontext kann aber zusätzliche Arbeit verhindern. Angenommen, der Agent sieht eine kompakte Fehlermeldung:

Test failed:
Expected 401
Received 500

Die vollständige Ausgabe hätte vielleicht auch das gezeigt:

Database connection refused
JWT middleware initialized correctly
Request reached /api/auth/login
PostgreSQL timeout after 5 seconds

Die Kurzfassung sagt dem Agenten, dass etwas fehlgeschlagen ist. Die vollständige sagt, dass die Authentifizierungslogik wahrscheinlich nicht schuld ist, sondern die Datenbankverbindung. Die zweite kostet mehr Token und spart vielleicht fünf Tool-Aufrufe. Kontext hat seinen Preis, fehlender Kontext aber auch. Die technische Herausforderung besteht darin, beides auszubalancieren.

Warum sich Agenten scheinbar im Kreis drehen

Sie haben wahrscheinlich schon gesehen, wie ein Agent so etwas macht:

Run command
↓
Read partial output
↓
Run another command
↓
Search same file
↓
Run original command again
↓
Read more output
↓
Change code
↓
Run test
↓
Go back to original command

Das wirkt wie Verwirrung, und manchmal ist es das auch. Manchmal hat die Infrastruktur dem Modell aber schlicht nicht genug Informationen gegeben, und der Agent gleicht eine unvollständige Schnittstelle aus. Wenn ein Agent immer wieder nach demselben fragt, liegt der Fehler womöglich im Tool-Design und nicht im Modell.

Tool-Design ist UX für Modelle

Entwickler beurteilen APIs meist nach Eingaben, Ausgaben, Latenz, Fehlern und Authentifizierung. Tools für KI brauchen eine weitere Frage: Wie beeinflusst diese Ausgabe die nächste Entscheidung des Modells? Nehmen wir zwei Antworten. API A:

{
  "status": "failed"
}

und API B:

{
  "status": "failed",
  "error": "PostgreSQL connection timeout",
  "service": "auth-api",
  "retryable": true,
  "attempt": 2,
  "duration_ms": 5040
}

B enthält mehr und kann trotzdem die Gesamtkosten des Systems senken, weil der Agent sofort richtig entscheiden kann. Das Ziel ist nicht das kleinstmögliche JSON. Es sind die Informationen, mit denen der Agent die nächste richtige Entscheidung trifft.

Die ganze Schleife optimieren

GitHub behandelt das nicht als einzelnes Kompressionsproblem. Der Bericht nennt mehrere Änderungen am Harness: nützlichen Kontext behalten und Wiederholungen streichen, Formatierung weglassen, die der Aufgabe nicht hilft, Anweisungen kürzen, ohne das Verhalten zu ändern, und unnötige Retrieval-Schritte bei Hintergrundarbeit vermeiden. Jede Änderung wurde offline auf Benchmarks für agentisches Programmieren bewertet und vor dem Ausrollen in kontrollierten Online-Experimenten bestätigt.

Das ist Performance-Engineering für Agenten. Die Frage verschiebt sich von „Wie mache ich eine Antwort kürzer?“ zu „Wie helfe ich dem Agenten, mit weniger verschwendeter Arbeit fertig zu werden?“, und das ist die weitaus bessere Frage.

Observability für Agenten

Das verändert, was Sie in Produktion messen. Bei gewöhnlichen Diensten würden Sie Folgendes beobachten:

Latency
Error rate
CPU
Memory
Throughput

Bei Agenten kommt mehr hinzu:

Task completion rate
Tool-call count
Retry rate
Repeated-command rate
Context growth
Model escalation rate
Time to completion
Cost per completed task
Human intervention rate

Die meisten davon sind Workflow-Metriken, keine Token-Metriken. Token zählen weiterhin, fließen aber in die Wirtschaftlichkeit ein, statt die Effizienz zu definieren.

Kosten pro erfolgreicher Aufgabe

Die einfachste mögliche Änderung: hören Sie auf, das hier zu messen:

cost per request

und messen Sie stattdessen das:

cost per successfully completed task

Das ist nicht dasselbe. Nehmen wir einen Agenten mit diesen Zahlen:

Agent A
$0.20/task
70% success rate

im Vergleich zu diesem:

Agent B
$0.35/task
95% success rate

Die billigere Anfrage ist nicht unbedingt das billigere System. Normalisieren wir:

Effective cost
= inference cost / successful tasks

Für A:

$0.20 / 0.70
≈ $0.286

Für B:

$0.35 / 0.95
≈ $0.368

Nach dieser einfachen Metrik gewinnt A trotzdem. Braucht A aber deutlich mehr Aufsicht durch Entwickler, verschiebt sich die Rechnung erneut. Deshalb brauchen Teams irgendwann eine breitere Definition von Aufgabenkosten.

Dieselbe Idee gilt bei der Modellwahl

Das hängt mit dem Trend zum Model Routing zusammen. GitHubs Research-Preview HydraFusion behandelt Coding-Workflows bereits als Optimierungsproblem und wählt pro Aufgabe zwischen einem einzelnen Modell, einer Eskalation zu stärkeren Modellen oder einem zweiten Modell als unabhängigem Kritiker. Offline-Tests unter kontrollierten Bedingungen zeigten Berichten zufolge große geschätzte Einsparungen, bei einer Qualität, die auf einigen Benchmarks der verwendeten Opus-5-Baseline entsprach oder darüber lag.

Verbinden Sie das mit der Lektion über Ausgaben. Ein kluger Agent fragt nicht bloß, welches Modell am billigsten ist. Er fragt, welcher Workflow diese Aufgabe mit der geringsten Verschwendung erledigt. Dieser Workflow könnte Folgendes kombinieren:

Cheap model
+
Good context
+
Efficient tools
+
Verification

und diesen hier schlagen:

Expensive model
+
Poor context
+
Repeated tool calls

Die Intelligenz steckt nicht mehr nur im Modell. Sie verteilt sich über das ganze System.

Wenn Sie KI-Produkte bauen

Es ist verlockend, zuerst die offensichtlichen Zahlen zu optimieren: weniger Tokenverbrauch, kleinere Prompts, kürzere Ausgaben, billigere Modelle. Optimieren Sie diese nicht isoliert. Instrumentieren Sie den gesamten Workflow:

User request
    ↓
Model inference
    ↓
Tool call
    ↓
Tool response
    ↓
Model reasoning
    ↓
Another tool call
    ↓
Verification
    ↓
Final result

Messen Sie jede Stufe und fragen Sie dann, wo der Agent unnötige Arbeit leistet. Vielleicht liefert das Datenbank-Tool zu wenig Kontext oder das Such-Tool zu viel Irrelevantes. Vielleicht wiederholt der Agent Versuche ohne Grund, oder Ihr Prompt erzwingt überflüssige Planung. Vielleicht würde ein stärkeres Modell die Aufgabe in der Hälfte der Runden lösen, oder ein billigeres reicht für einen ersten Versuch völlig aus. Das sind Probleme der Softwareentwicklung.

Die Zukunft heißt nicht weniger Token

Es ist verlockend, das ganze Kostenproblem darauf zu reduzieren:

tokens ↓
cost ↓

Der tatsächliche Zusammenhang sieht eher so aus:

Useful context
      ↓
Better decisions
      ↓
Fewer retries
      ↓
Fewer unnecessary tool calls
      ↓
Shorter task duration
      ↓
Lower total cost

Manchmal beginnt der Weg zu geringeren Kosten damit, dem Modell mehr Informationen zu geben. Das ist der kontraintuitive Teil, und genau deshalb wird KI-Engineering zu einer Systemdisziplin statt zu einer Übung im Prompt-Schreiben.

Messen Sie erledigte Arbeit

Wenn Sie einen Agenten bewerten, fragen Sie nicht nur, wie viele Token er verbraucht hat. Fragen Sie, wie viel nützliche Software er geliefert und wie viel Arbeit er auf dem Weg dorthin verschwendet hat. Das heißt: Korrektheit, Latenz, Tool-Aufrufe, Wiederholungen, Kontextgröße, Inferenzkosten, menschliche Eingriffe und erfolgreichen Abschluss messen.

Das siegreiche Coding-System wird nicht unbedingt die wenigsten Token ausgeben. Eher wird es das Setup sein, das jeden Token, jeden Tool-Aufruf und jede Modellwahl in echten Fortschritt verwandelt. GitHubs jüngste Engineering-Arbeit zeigt die Richtung: die ganze Aufgabe optimieren, die Informationen behalten, die der Agent braucht, und Arbeit nur dann streichen, wenn man weiß, dass sie nicht hilft. Es geht nicht darum, dass Agenten weniger tun. Es geht darum, dass sie weniger verschwenden.