Wenn ein Coding Agent sein Context Window mitten in einer Aufgabe erschöpft, stürzt er nicht ab. Er degradiert. Edits beginnen über Dateien hinweg zu bluten. Variablennamen driften. Der Agent produziert selbstbewusst einen PR, der auf den ersten Blick vernünftig aussieht und beim Review auseinanderfällt. Der Fehlermodus ist nicht „der Agent hat aufgehört“ — es ist „der Agent hat weitergemacht, aber schlechter.“
Token-Verbrauch in agentischen Sessions ist ein Korrektheitsproblem, kein Kostenproblem. Context-Budget ist ein Produktions-SLA.
Chat-Gewohnheiten sind Agent-Anti-Patterns
In interaktivem Chat mit einem LLM ist es sinnvoll, mehrere Fragen in einer Nachricht zu bündeln. Es vermeidet das erneute Senden der gesamten Konversationshistorie bei jeder Anfrage. Menschen tragen diese Gewohnheit direkt in agentisches Coding: „Wenn du schon dabei bist, fix auch das Logging in Modul X und aktualisier die README.“
Für einen Coding Agent ist das das Gegenteil von hilfreich. Jedes zusätzliche Anliegen lädt Code, Tests und Reasoning-State in dasselbe Context Window. Mitte der Session hält der Agent drei unzusammenhängende Änderungen gleichzeitig. Seine Edits beginnen über Concerns hinweg zu bluten. Der Mensch reviewt am Ende einen PR, der einen Bugfix mit einem Refactoring mit einem Docs-Update mischt — und kann keines davon sauber reverten.
Das Interaktionsmodell, das für Chat funktioniert (bündeln um Round-Trips zu sparen), ist ein Anti-Pattern für Agents (isolieren um Kohärenz zu bewahren). Ein Issue, eine Session. Wenn ein Agent an Issue #42 arbeitet und ein verwandtes Problem in #43 entdeckt, ist der Instinkt, beides zu fixen. Nicht tun. #42 abschließen, Session beenden, neue öffnen. Das wurde gelernt, nachdem Sessions scharf starteten und ab der 60%-Context-Marke in inkohärente Edits degradierten.
MCP Tools: Strukturiert, Discoverable — und verschwenderisch
MCP (Model Context Protocol) ist der natürliche Integrationspunkt für LLM Agents. Strukturierter Input/Output, typisierte Parameter, discoverable Schemas. Sauberes Engineering. Und in vielen Fällen ein Context-Window-Drain.
Das Problem ist nicht MCP selbst — es ist was passiert, wenn MCP eine REST-API wrappt. Ein einzelner list_issues-Call gegen GitHub liefert jedes Feld auf jedem Issue: Body, Reactions, Timeline, Assignees, vollständige Label-Objekte. Der Agent braucht fünf Felder. Er bekommt fünfzig. Multipliziert mit sechs Repositories, täglich ausgeführt, und die Token-Kosten für Daten, die der Agent nie liest, werden zur dominanten Ausgabe in der Session.
Für den Portfolio-Sync Skill — einen täglichen Statusbericht über sechs Repositories — habe ich die MCP-list_issues-Calls durch ein eigenständiges Python-Script ersetzt, das GitHubs GraphQL-Endpoint direkt anspricht. Die Query projiziert exakt fünf Felder: number, title, state, labels, updatedAt. Nichts anderes geht über die Leitung.
Das Script nutzt urllib — nur Stdlib, keine externen Dependencies. In einem gesandboxten Devcontainer mit Firewall-beschränktem Netzwerkzugang ist das relevant. Null Paketinstallationen, null Calls an npm oder PyPI, automatischer Proxy-Support. Der Agent reasont nicht über MCP-Connection-State oder Tool-Discovery. Er führt ein Script aus und bekommt ein JSON-Ergebnis.
Das Pattern generalisiert: Wenn ein Agent wiederholt denselben MCP-Tool in einer Schleife aufruft, erwäge ihn durch ein zweckgebautes Script zu ersetzen, das die Arbeit batchet, nur benötigte Felder projiziert und ein einzelnes strukturiertes Ergebnis zurückgibt. Dasselbe Pattern bei Playwright und GitHub CLI — beide bevorzugt gegenüber ihren MCP-Äquivalenten, weil CLI-Tools Agents composable, pipeable Output liefern, den sie mit Standard-Unix-Tools filtern können.
Das ist kein Argument gegen MCP. Es ist ein Argument dafür, bewusst zu entscheiden, wo Convenience-Tools ihre Token-Kosten verdienen und wo ein gezieltes Script denselben Job bei 5% des Context-Overheads erledigt.
Delta Caching: Was sich nicht geändert hat, nicht fetchen
Portfolio Sync läuft täglich. Die meisten Repos sind an einem gegebenen Tag ruhig. Ohne Caching fetchte jeder Lauf alle Issues aus allen Repos — dieselben Daten, dieselben Token-Kosten, dieselbe Verschwendung.
Der Fix ist ein Zwei-Modi-Fetch-System mit einem persistenten JSON-Cache. Das Invalidierungssignal ist der Commit-SHA, nicht ein Timer. Vergleiche den letzten Commit-SHA gegen den gecachten SHA — wenn unverändert und der Cache jünger als 24 Stunden ist, null API-Calls für dieses Repo. An einem typischen Tag treffen vier von sechs Repos diesen Pfad.
Wenn ein Repo neue Commits hat, ist der Fetch delta-only: nur Issues, die seit dem letzten Cache-Timestamp aktualisiert wurden. An einem ruhigen Tag sind das eine Handvoll Records statt Hunderte. State-Transitionen werden korrekt behandelt — GitHubs filterBy.since liefert jedes Issue, das nach dem Timestamp berührt wurde, inklusive neu geschlossener. Delta-Ergebnisse mergen per Issue-Nummer in den gecachten Index.
Die 24-Stunden-Obergrenze ist ein Sicherheitsnetz, nicht der primäre Invalidierungsmechanismus. Der SHA-Vergleich bedeutet: der Cache bleibt während Wochenenden oder ruhigen Phasen valide ohne arbiträres Ablaufen, refreshed aber sofort wenn echte Arbeit landet.
Vorher: vollständige REST-Payloads via MCP, jedes Repo, jeder Lauf. Nachher: zwei Delta-Fetches und vier Cache-Hits an einem typischen Tag. Kombiniert mit GraphQL-Feldprojektion sank der Token-Verbrauch für Issue-Daten um rund 95%.
Jede Interaktion ist eine Entnahme
Die vier Token-Efficiency-Patterns, die sich aus dem täglichen Betrieb von Agents gegen reale Infrastruktur ergeben haben, teilen dasselbe Prinzip: Jede Tool-Interaktion ist eine Entnahme aus einem endlichen Budget. Investiere es in die Aufgabe, nicht in Rauschen.
CI-Polling — niemals --watch. gh pr checks --watch streamt jeden CI-Zwischenzustand in den Context: „queued… in_progress… queued… in_progress…“ — 4-5x redundanter Output vor dem finalen Ergebnis. sleep 60 && gh pr checks <PR> liefert ein Ergebnis. Die Human-Version ist perfekt fürs Terminal-Watching. Die Agent-Version ist Context-Verschmutzung.
Build-Noise-Filtering. Ein nacktes dotnet build emittiert Restore-Logs, informationelle Warnungen, NuGet-Resolution-Messages — hunderte Zeilen, wo der Agent zwei braucht: „Build succeeded“ oder die Fehlerzeile. Ein Grep-Filter reduziert das auf Signal. Wenn der Fehler NU1301 ist (NuGet-Feed nicht erreichbar in der Sandbox), bricht der Agent sofort ab statt 40+ kaskadierende Fehler zu lesen, die alle denselben Root Cause haben.
Bounded File Reads. Dateien unbekannter Länge werden structure-first gelesen: 40 Zeilen um die Form zu scannen, dann gezielte Offset-Reads zur relevanten Sektion. Ein 2.000-Zeilen-Workflow-YAML, ungebunden in den Context gedumpt, kann 5-10% des gesamten Session-Budgets für Content verbrauchen, den der Agent nicht nutzt.
Abort statt Retry. Wenn ein Agent einen transienten Fehler trifft (Netzwerk-Timeout, NuGet-Feed down, flaky Test), ist der menschliche Instinkt: Retry. Für einen Agent multipliziert jeder Retry die Token-Kosten des Fehlers. Der Error-Output lädt in den Context, der Retry-Output lädt obendrauf, und wenn der Fehler persistiert, hat der Agent hunderte Tokens investiert ohne etwas zu lernen. Schnell scheitern, Root Cause berichten, den Menschen entscheiden lassen ob neugestartet wird.
Keines davon ist einzeln dramatisch. Sie addieren sich. Ein ausführliches Build-Log hier, ein Streaming-Statuscheck dort, ein unbegrenztes File-Read irgendwo anders — und der Agent erreicht 60% Context-Auslastung bevor er die Hälfte der Aufgabe geschafft hat. Danach degradiert die Kohärenz und der Mensch muss ohnehin eingreifen.
Die Frage, die sich bei jeder Tool-Interaktion lohnt wenn man agentische Infrastruktur zu optimieren will: Braucht der Agent diesen Output wirklich, in diesem Umfang, in dieser Granularität?
Context Window ist kein Speicher. Es ist Aufmerksamkeit. Und Aufmerksamkeit, die für Rauschen ausgegeben wird, steht für die Arbeit nicht mehr zur Verfügung.