So reduzieren Sie Agent-Token-Kosten in CLI-Workflows

Ich bin Dora. Letzten Monat habe ich einen einzigen npm-Test durch Claude Code laufen lassen und zugeschaut, wie die Sitzung rund 12.000 Input-Token verbrannt hat, bevor der Agent auch nur ein Wort zurückgab. Die Testausgabe war 400 Zeilen lang. Vielleicht 30 davon waren relevant. Der Rest — Deprecation-Warnungen, Dependency-Rauschen, Jests Fortschrittspunkte — alles davon landete direkt im Kontext des Modells. Ich habe für jedes Byte bezahlt.

Das war der Moment, in dem ich aufhörte, Token als „etwas, das das Modell handhabt” zu betrachten, und anfing, sie als ein Budget zu behandeln, das ich aktiv verlor. Wenn du agentische CLI-Workflows auf Claude Code, Gemini CLI oder ähnlichem betreibst, ist das wahrscheinlich dein größter Kostenfaktor — und die Lösung ist kein besseres Modell, sondern bessere Hygiene. Anthropics eigene Kostenmanagement-Dokumentation bringt es auf den Punkt: Token-Kosten skalieren mit der Kontextgröße, und die meisten Optimierungen passieren bevor das Modell die Daten überhaupt sieht. Dieser Beitrag erklärt, wie man Agent-Token-Kosten in CLI-Workflows reduziert, ohne das nötige Debugging-Signal zu verlieren.

Wo CLI-Workflows Token verschwenden

Bevor ich irgendetwas behebt konnte, musste ich herausfinden, wo die Lecks waren. Zwei Muster stachen hervor, und sie tauchen in fast jedem CLI-Workflow auf, den ich seitdem geprüft habe.

Ausführliche Befehle und irrelevante Ausgaben

Terminalbefehle wurden für Menschen entwickelt, die einen Bildschirm überfliegen, nicht für LLMs, die Byte für Byte lesen. git status gibt ANSI-Codes aus, die das Modell nicht braucht. npm install wirft tausend Zeilen Dependency-Baum aus, den das Modell bereits kennt. next build echot seinen eigenen Fortschritt für fünfzehn Sekunden. Nichts davon rechtfertigt seinen Platz im Kontextfenster.

Die Zahlen sind schlimmer als sie auf dem Papier aussehen. Ein einzelner cargo test-Lauf in einem mittelgroßen Rust-Projekt kann 8.000–15.000 Token Ausgabe erzeugen. Der Großteil davon ist Kompilierungs-Rauschen. Wenn der Agent alles davon liest, um eine fehlschlagende Assertion zu finden, hast du Opus-Tarife für das Streaming eines Build-Logs bezahlt.

Das ist auch der Grund, warum Community-Projekte wie rtk und tokf existieren — sie sitzen zwischen der Shell und dem Agent, filtern Boilerplate heraus, bevor sie den Kontext erreicht, und berichten von Einsparungen im Bereich von 70–90 % bei gängigen Befehlen. Ob du einen Wrapper verwendest oder nicht, das Prinzip gilt: Rohe Terminal-Ausgabe ist keine LLM-taugliche Daten.

Kontext-Übertrag und wiederholte Lesevorgänge

Das zweite Leck ist subtiler. Jeder Tool-Aufruf, den der Agent macht — Datei lesen, grep, bash-Befehl — bleibt im Gesprächsverlauf. Bei Schritt zehn verarbeitet das Modell bei jeder Anfrage neun Schritte veralteter Ausgaben erneut. Anthropics eigener April-Postmortem zu Claude Code-Qualitätsproblemen beschreibt genau diese Dynamik: Ein Caching-Bug verursachte, dass der Denkprozess-Verlauf sich über Schritte ansammelte, und die Token-Nutzung blähte sich 10–20-fach auf, bevor jemand es bemerkte. Selbst ohne Bugs ist das das Standardverhalten. Lange Sitzungen sind teure Sitzungen.

Ich überprüfte eine meiner eigenen, eine Woche alten Sitzungen. Der Agent hatte dieselbe package.json viermal gelesen. Keiner dieser erneuten Lesevorgänge fügte Information hinzu — die Datei hatte sich nicht geändert. Es waren nur Artefakte davon, dass der Agent nicht wusste, was er bereits wusste.

Schritt 1: Lautes Rauschen in Ausgaben komprimieren

Die günstigste Lösung, mit großem Abstand, besteht darin, Datenmüll gar nicht erst in den Kontext zu lassen. Drei Regeln, in dieser Reihenfolge:

An der Quelle filtern, nicht danach. Statt npm test führt der Agent npm test --silent 2>&1 | grep -E "(FAIL|PASS|Error)" aus. Statt git status führt er git status --short aus. Statt cargo build führt er cargo build --quiet 2>&1 | tail -20 aus. Das ist nicht clever. Es ist schlicht Disziplin. Der Agent bekommt den fehlschlagenden Test, die geänderten Dateien, den eigentlichen Fehler — sonst nichts.

Tool-Ausgabe auf Harness-Ebene begrenzen. Claude Code erlaubt es, eine maximale Tool-Ausgabegröße festzulegen. Ich habe meine auf 8.000 Zeichen pro Aufruf reduziert. Wenn ein Befehl das überschreitet, erhält der Agent einen Kürzungshinweis und entscheidet, ob er die Abfrage verfeinern soll. Diese einzelne Einstellung hat mir mehr Token gespart als alle anderen Änderungen zusammen.

Einen CLI-Proxy verwenden, wenn das Upstream-Tool nicht schweigen will. Manche Befehle haben kein nützliches Quiet-Flag — next build, webpack, alles Java-basierte. Für diese ist ein Wrapper, der bekanntes Boilerplate entfernt, den Einrichtungsaufwand wert. Tools aus der rtk/tokf-Familie erledigen das generisch; man kann auch eine 30-zeilige Bash-Funktion für die drei Befehle schreiben, die einem am meisten Probleme machen.

Es gibt einen echten Trade-off. Aggressive Komprimierung kann Debugging-Signale verbergen. Wenn ein Build aus einem Grund fehlschlägt, den der Filter entfernt — eine Deprecation-Warnung, die zu einem Fehler wurde, ein obskures Konfigurationsproblem in Zeile 847 — bekommt der Agent ein kürzeres, weniger nützliches Bild. Das ist mir zweimal passiert. Beide Male war die Lösung, eine Filterregel zu lockern, nicht die Strategie aufzugeben.

Schritt 2: Kontext begrenzen, bevor er das Modell erreicht

Ausgabefilterung behandelt die neuen Token, die in jeden Schritt eintreten. Kontext-Disziplin behandelt die angesammelten Token, die bereits in der Sitzung sind. Unterschiedliche Probleme.

Die beiden wichtigen Befehle, beide direkt aus Anthropics Claude Code Best Practices, sind /clear und /compact. /clear setzt die Sitzung vollständig zurück — nützlich beim Wechsel zu einer nicht verwandten Aufgabe. /compact fasst den frühen Verlauf zusammen, behält aber wichtige Entscheidungen und den aktuellen Zustand — nützlich, wenn die Aufgabe fortgesetzt wird, die frühe Exploration aber nicht mehr relevant ist. Claude Code komprimiert automatisch, wenn Kontextlimits erreicht werden, aber auf diesen Auslöser zu warten ist meist zu spät. Bis dahin hat man bereits den aufgeblähten Tarif für mehrere Schritte bezahlt.

Meine aktuelle Gewohnheit: Ich führe /compact an jeder natürlichen Aufgabengrenze aus, mit einer Anweisung wie /compact Focus on the failing test and the recent file edits. Die Anweisung ist wichtig. Ohne sie fasst die Komprimierung alles grob zusammen. Mit ihr behält der Agent die Teile, die für die nächste Phase relevant sind.

Für API-basierte Agenten (nicht das CLI-Abonnement) beschreibt Anthropics Kontext-Bearbeitungs-Dokumentation einen strengeren Mechanismus: clear_tool_uses_20250919 löscht automatisch alte Tool-Ergebnisse, sobald der Kontext einen Schwellenwert überschreitet. Der Agent behält das Gespräch, verliert aber die Rohdaten, die er bereits verarbeitet hat. Für langfristige agentische Aufgaben ist das die richtige Standardeinstellung.

Eines möchte ich noch ansprechen: Ein überladenes CLAUDE.md ist eine permanente Steuer. Es wird bei jedem Schritt, jeder Sitzung, immer geladen. Ich habe meines von ~280 Zeilen auf ~90 gekürzt. Der Token-Zählwert pro Schritt fiel merklich, und das Verhalten des Agents änderte sich in keiner messbaren Weise.

Schritt 3: Agent-Tooling für geringere Verschwendung neu gestalten

Die ersten beiden Schritte sind taktisch. Dieser hier ist strukturell, und hier liegen die dauerhaften Einsparungen.

Tools entwerfen, die LLM-freundliche Ausgaben erzeugen. Die Community-getriebene CLI Spec macht dieses Argument besser als ich es könnte: Befehle für Agenten sollten ein --output-Flag unterstützen, Daten (stdout) von Diagnosen (stderr) trennen und Paginierung statt unbegrenztem JSON-Dump bieten. Wenn du interne CLIs baust, die deine Agenten aufrufen, folge dieser Spec. Wenn du externe CLIs verwendest, die das nicht tun, umhülle sie.

Enge Tools breiten vorziehen. Eine git_status_summary-Funktion, die drei strukturierte Felder zurückgibt, ist besser, als den Agent rohe git status-Ausgabe parsen zu lassen. Jede Parsing-Schicht, die das Modell durchführen muss, ist eine Schicht, in der Token für Übersetzung statt für Schlussfolgerung verbrannt werden. Ich habe vier meiner am häufigsten verwendeten Befehle in schlanke Python-Wrapper umgewandelt, die JSON zurückgeben. Die Token-Nutzung pro Roundtrip bei diesen Operationen sank um etwa 60 %.

Subagents für lesintensive Arbeit nutzen. Die Subagent-Funktion von Claude Code führt einen separaten Kontext für Aufgaben wie „das Repo durchsuchen und den Auth-Flow zusammenfassen” aus. Die Ergebnisse kommen als kompakte Zusammenfassung zurück — nicht als die 40 Dateien, die der Subagent tatsächlich gelesen hat. Das Hauptgespräch sieht die Rohdaten nie. Für explorationsschwere Aufgaben ist das der einzige verfügbare strukturelle Hauptgewinn.

Das Modell auf die Arbeit abstimmen. Opus 4.7 ist beeindruckend und teuer. Die meiste CLI-Arbeit — Dateibearbeitungen, Test-Fixes, routinemäßige Refactors — läuft gut auf Sonnet, zu etwa 40 % von Opus’ Per-Token-Kosten. Wissenswert: Opus 4.7s neuer Tokenizer kann bei identischem Text bis zu 35 % mehr Token erzeugen als frühere Modelle, was den Kostenvorteil verstärkt.

Der ehrliche Vorbehalt: Messen, bevor man optimiert, dann erneut messen. Ich habe eine Woche lang eine Baseline mit /cost (API) oder /usage (Abonnement) gemessen, bevor ich irgendetwas änderte, und nach jeder Änderung neu gemessen. Zwei meiner „Optimierungen” stellten sich als nichts Messbares heraus. Ohne Baseline rät man nur.

FAQ

Warum verbrauchen Terminal-Workflows so viele Token?

Weil Terminal-Ausgabe für Menschen konzipiert wurde, und Agenten Byte für Byte bezahlen. Ein typischer Build-Befehl gibt Tausende von Zeilen Fortschritt, Warnungen und Boilerplate aus, die das Modell nicht braucht. Kombiniert man das mit einem Gesprächsverlauf, der sich nie zurücksetzt, und Tool-Ergebnissen, die sich über Schritte ansammeln, entstehen Sitzungen, die Kontextbudgets verbrennen, bevor die eigentliche Arbeit beginnt.

Wie viel kann Ausgabenkomprimierung helfen?

Nach meinen Messungen reduzierten Befehlsebenen-Filterung plus Ausgabe-Obergrenzen die Input-Token pro Schritt bei Testläufen, Builds und Git-Operationen um 40–60 %. Community-Wrapper wie rtk berichten von 80–90 % Reduktionen bei bestimmten Befehlen, obwohl diese Zahlen von der schlimmstmöglichen ausführlichen Ausgabe ausgehen. Realistische Gewinne hängen davon ab, welche Befehle dein Agent am häufigsten ausführt. Die fünf häufigsten prüfen, diese beheben, und der Großteil der Einsparungen taucht sofort auf.

Was sollten Teams zuerst optimieren?

In dieser Reihenfolge: Tool-Ausgabe-Obergrenzen, /clear- und /compact-Disziplin, Modellauswahl. Ausgabe-Obergrenzen sind eine einmalige Konfigurationsänderung ohne laufende Kosten. Sitzungs-Hygiene ist eine Gewohnheit, aber kostenlos, sobald man sie verinnerlicht hat. Modellauswahl ist der am leichtesten zu übersehende Gewinn — alles auf Opus laufen zu lassen, wenn die meisten Aufgaben gut auf Sonnet funktionieren, ist ein stilles, großes Leck.

Wann schadet Token-Optimierung der Debugging-Qualität?

Wenn man über den Punkt hinaus komprimiert, wo der Agent sehen kann, was kaputt gegangen ist. Ein gekürzter Stack-Trace, eine herausgefilterte Deprecation-Warnung, ein --quiet-Flag, das den echten Fehler verbirgt — all das hat mir echte Zeit gekostet. Das Muster, dem ich folge: aggressiv bei Routine-Befehlen komprimieren (git status, npm install, erfolgreiche Testläufe), ausführliche Ausgaben für bekannt fehlschlagende oder unbekannte Operationen behalten. Wenn man einen Befehl ohne Filter erneut ausführt, um zu debuggen, war der Filter falsch, nicht die Strategie.

Fazit

Token-Kosten in CLI-Workflows sind kein Modell-Problem. Sie sind ein Klempner-Problem. Der Großteil der Ausgaben versickert in der Lücke zwischen dem, was Terminalbefehle ausgeben, und dem, was das Modell tatsächlich braucht, um zu schlussfolgern — und diese Lücke ist mit Ausgabe-Filterung, Kontext-Disziplin und Tooling, das den Agenten am anderen Ende respektiert, behebbar.

Ich betreibe das oben beschriebene Setup seit etwa sechs Wochen. Der tägliche Token-Verbrauch auf Claude Code ist um etwa 55 % gesunken, die Agent-Latenz verbesserte sich als Nebeneffekt kleinerer Kontexte, und der Workflow fühlt sich beim Debuggen weniger rauschig an. Keine dieser Zahlen ist universell — deine Baseline und deine fünf häufigsten Befehle werden anders aussehen. Aber das Muster gilt: Kontrolliere, was in den Kontext eintritt, kontrolliere, was im Kontext bleibt, und lass das Modell sein Budget für Schlussfolgerungen statt für das Lesen von Build-Logs ausgeben.

Das ist, wo meine Daten enden. Die Komprimierungsschicht entwickelt sich weiter, und Anthropics Tokenizer-Änderungen bedeuten, dass diese Zahlen eine Haltbarkeit haben. Es lohnt sich, jedes Quartal eine neue Baseline zu erheben.

Frühere Beiträge:

• What Is RTK Token Efficiency?
• Agentic Workflow Tool Wiring Patterns & Pitfalls
• MCP in Production: Model Context Protocol Workflows
• Claude Code Agent Harness Architecture
• Claude Code vs Cursor 2026