# Agent Token Kosten reduzieren per CLI (2026 Anleitung) > Source: > Published: 2026-05-20 08:41:46+00:00 Ein CLI-Codierungsagent fühlt sich frei an, bis die Rechnung kommt. Sie richten Claude Code oder Codex auf ein Repository, lassen ein Modul refaktorisieren, und zehn Minuten später hat der Agent vierzig Dateien gelesen, die Testsuite dreimal ausgeführt und sechsstellige Token-Mengen für Kontext verbraucht, den er nie gebraucht hätte. In einem Team mit mehreren Entwicklern wird daraus schnell ein echter Kostenfaktor. Die gute Nachricht: Ein großer Teil dieser Token-Kosten lässt sich direkt über CLI-Workflows, Konfiguration und bessere Prompts reduzieren. ## TL;DR Reduzieren Sie Token-Kosten von CLI-Agenten, indem Sie den Kontext begrenzen, bevor er das Modell erreicht: - Arbeitssatz explizit eingrenzen - Speicherdateien wie `CLAUDE.md` kurz halten - lange Sitzungen mit `/compact` oder`/clear` kürzen - Prompt-Caching für stabile Präfixe aktivieren - einfache Unteraufgaben an günstigere Modelle routen - Tool-Ausgaben filtern - Kosten pro Lauf messen Das Ziel ist nicht, schlechtere Modelle oder weniger Automatisierung zu nutzen. Das Ziel ist, keine Tokens für irrelevanten Kontext zu bezahlen. ## Einführung Token-Kosten zeigen sich meist auf zwei Arten: - Sie erreichen mitten in einer Aufgabe ein Wochen- oder Sitzungslimit. - Die monatliche API-Rechnung ist deutlich höher als erwartet. Beides hat dieselbe Ursache: CLI-Agenten sind standardmäßig kontexthungrig. Sie lesen ganze Dateien, wenn zehn Zeilen reichen würden. Sie senden die gesamte Unterhaltung bei jeder Runde erneut. Sie leiten rohe Test- und Build-Logs zurück in den Kontext. Und sie übertragen dieselben System-Prompts, Tool-Definitionen und Repo-Konventionen hunderte oder tausende Male pro Tag. Eine Refaktorisierung, die wirklich über 2.000 Tokens Code nachdenken muss, braucht keine 180.000 Tokens Kontext. Die Differenz ist Ihr Einsparpotenzial. Dieser Leitfaden zeigt konkrete Maßnahmen für: - Kontexthygiene und Speicherdateien - Prompt-Caching - Modell-Routing - kürzere Tool-Ausgaben - gezielte Dateiabrufe - Kostenmessung pro Agentenlauf Die Beispiele beziehen sich auf Claude Code und Codex, gelten aber für jeden CLI-Agenten, der über eine tokenbasierte API abgerechnet wird. Ein zusätzlicher Kostenfaktor ist Debugging. Wenn ein Agent eine fehlerhafte interne API aufruft, wiederholt er Requests, liest Fehlertexte, lädt Dokumentation erneut und kann in teuren Schleifen hängen bleiben. 💡 Wenn Ihre Agenten APIs nutzen, lohnt es sich, diese APIs vorher in Apidog zu designen, zu mocken und zu testen. Der Agent arbeitet dann gegen einen stabilen Vertrag statt gegen einen Live-Endpunkt, der unerwartet reagiert. Das reduziert teure Trial-and-Error-Schleifen. ## Wohin Tokens bei einem CLI-Agentenlauf gehen Eine Agentenrunde besteht aus: - Eingabe-Payload an das Modell - Ausgabe-Payload vom Modell Sie zahlen für beides. Bei vielen Anbietern sind Output-Tokens deutlich teurer als Input-Tokens. Die konkreten Preise ändern sich, aber die Struktur bleibt gleich: Output ist teuer, und Input explodiert durch wiederholten Kontext. Typische Token-Quellen: **System-Prompt und Tool-Definitionen** Agentenanweisungen plus JSON-Schemas aller Tools. Oft 5.000 bis 15.000 Tokens pro Runde.**Speicher- und Projektdateien** Dateien wie`CLAUDE.md` , Repo-Konventionen oder persistente Regeln. Sie werden häufig bei jeder Runde geladen.**Gesprächsverlauf** Frühere Benutzernachrichten, Modellantworten, Tool-Aufrufe und Tool-Ergebnisse. Dieser Verlauf wächst mit jeder Runde.**Gelesene Dateien** Ein`Read` einer Datei mit 1.200 Zeilen kann schnell 12.000 bis 18.000 Tokens kosten.**Tool-Ausgabe** Testlogs,`npm install` -Ausgaben, Stacktraces, Lockfile-Diffs und Build-Rauschen. Der wichtigste Punkt: Der Gesprächsverlauf wird bei jeder Runde erneut gesendet. Eine 30-Runden-Sitzung kostet nicht einfach 30 einzelne Runden. Spätere Runden tragen den gesamten bisherigen Kontext mit. Wenn Sie tiefer verstehen möchten, wie Sitzungen und Limits in der Praxis abgerechnet werden, lesen Sie ergänzend [wie das Token-Fenster von Claude Code zurückgesetzt wird](http://apidog.com/blog/claude-code-token-window-reset?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). ## Kontexthygiene und Speicherdateien Das billigste Token ist das, das Sie nie senden. Kontexthygiene ist deshalb der wichtigste Hebel. ### 1. Arbeitssatz vor dem Start eingrenzen Starten Sie den Agenten nicht im Repo-Root mit einem vagen Auftrag wie: ``` claude "refactor the billing logic" ``` Das lädt den Agenten dazu ein, das Repository breit zu durchsuchen. Besser: ``` claude "refactor the retry logic so it uses exponential backoff, only in src/payments/retry.ts and its test file" ``` Noch besser, wenn Sie das Zielverhalten explizit machen: ``` claude "In src/payments/retry.ts, replace the fixed retry delay with exponential backoff. Update only the related tests in src/payments/retry.test.ts. Do not inspect unrelated payment modules unless a test failure requires it." ``` Das spart Tokens, weil der Agent nicht erst zwanzig Dateien lesen muss, um die zwei relevanten zu finden. ### 2. Speicherdateien kurz halten Eine Datei wie `CLAUDE.md` wird oft bei jeder Runde in den Kontext geladen. Wenn sie wie ein Wiki behandelt wird, zahlen Sie dauerhaft für irrelevanten Text. Prüfen Sie grob die Größe: ``` wc -c CLAUDE.md | awk '{print "≈", int($1/4), "tokens per turn"}' ``` Eine gute `CLAUDE.md` enthält: ``` # Project instructions ## Build - npm run build ## Test - npm test - npm run test:unit -- --runInBand for focused unit runs ## Conventions - Use TypeScript strict mode. - Keep public API changes backward-compatible. - Prefer small focused diffs. ## Docs - API contract docs live in docs/api.md. - Payment retry behavior is documented in docs/payments/retry.md. ``` Vermeiden Sie: - lange Architekturhistorien - vollständige API-Dokumentation - Onboarding-Texte - selten relevante Spezialfälle Verlinken Sie stattdessen auf tiefere Dokumente, die der Agent nur bei Bedarf lesen soll. ### 3. Lange Sitzungen kompaktieren oder zurücksetzen Wenn eine Aufgabe abgeschlossen ist, starten Sie nicht direkt die nächste Aufgabe im selben Verlauf. Sonst trägt jede neue Runde das alte Transkript mit. In Claude Code: ``` /compact ``` Das fasst den Verlauf zusammen und verwirft das rohe Transkript. Für einen echten Neustart: ``` /clear ``` Praktische Regel: - eine logische Aufgabe pro Sitzung - nach Abschluss `/compact` oder`/clear` - keine unabhängigen Aufgaben im selben Kontext stapeln Die Muster in den [Claude Code Workflows](http://apidog.com/blog/claude-code-workflows?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) bauen stark auf diesem Scoping auf. ### 4. Ignorierdateien nutzen Halten Sie generierte oder große Dateien außerhalb der Reichweite des Agenten: ``` node_modules/ dist/ build/ coverage/ *.lock *.log ``` Wenn Ihr Agent eine eigene Ignore-Datei unterstützt, ergänzen Sie dort zusätzlich: ``` docs/generated/ openapi.generated.json large-fixtures/ ``` Alles, was der Agent nicht sieht, kann er nicht lesen, diffen oder erneut in den Kontext laden. ## Prompt-Caching: Nicht mehrfach für dasselbe Präfix zahlen Prompt-Caching speichert stabile Teile Ihrer Anfrage, etwa: - Tool-Definitionen - System-Prompt - Repo-Konventionen - statische Projektregeln Nachfolgende Anfragen mit demselben Präfix können diesen Teil günstiger wiederverwenden. Die Grundregel: ``` stabiler Kontext zuerst flüchtiger Kontext zuletzt ``` Typische Reihenfolge: ``` tools → system → messages ``` Alles, was sich häufig ändert, gehört hinter den Cache-Breakpoint: - aktuelle Benutzernachricht - Zeitstempel - frisch gelesene Dateien - aktuelle Tool-Ergebnisse Wenn Sie einen eigenen Wrapper verwenden, können Sie Caching explizit setzen: ``` response = client.messages.create( model="claude-sonnet-4-6", max_tokens=2048, system=[ { "type": "text", "text": SYSTEM_PROMPT + REPO_CONVENTIONS, "cache_control": {"type": "ephemeral"}, } ], messages=[ { "role": "user", "content": user_task, } ], ) u = response.usage print("cache write:", u.cache_creation_input_tokens) print("cache read :", u.cache_read_input_tokens) print("fresh input:", u.input_tokens) ``` Wichtig für stabile Cache-Treffer: - keine Zeitstempel im gecachten Bereich - keine zufälligen IDs im System-Prompt - gleiche Tool-Reihenfolge - gleiche Formatierung - stabile Repo-Konventionen Ein täglicher Refactor-Agent mit einem 8.000-Token-Konventionsblock und 60 Aufrufen pro Tag ist ein klassischer Anwendungsfall. Ohne Caching zahlen Sie den Block 60-mal vollständig. Mit Caching zahlen Sie einmal den Schreibvorgang und danach deutlich günstigere Cache-Reads. Die OpenAI-API bietet bei unterstützten Modellen ein ähnliches Prinzip für gecachte Eingaben. Details unterscheiden sich, aber das Muster bleibt gleich: stabile Präfixe lohnen sich. Wenn Caching allein nicht reicht, sind die Free-Tier- und Routing-Muster im Artikel zum [kostenlosen Betrieb von GPT-5.5 über Codex](http://apidog.com/blog/how-to-use-gpt-5-5-free-codex?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) eine sinnvolle Ergänzung. ## Modell-Routing: Günstiges Modell für einfache Arbeit Nicht jede Agentenaktion braucht ein Frontier-Modell. Diese Aufgaben eignen sich oft für ein günstigeres Modell: - Commit-Nachrichten schreiben - Changelog-Einträge formulieren - Diffs zusammenfassen - einfache Tests generieren - Lint-Fehler erklären - Boilerplate erstellen - Symbolnamen konsistent umbenennen Beispiel: ``` claude --model haiku "write a conventional-commit message for the staged diff" claude --model sonnet "redesign the caching layer for the payments service" ``` Die bessere Standardstrategie: ``` günstiges Modell als Default teures Modell nur bei Bedarf ``` Viele Teams machen es umgekehrt und lassen alles „zur Sicherheit“ über das teuerste Modell laufen. Das ist besonders teuer bei hochfrequenten Aufgaben wie Commit-Messages oder kleinen Testanpassungen. ### Unteragenten gezielt routen Wenn Ihr Framework Unteragenten unterstützt, geben Sie ihnen: - kleines Modell - kleinen Kontext - eng definierte Aufgabe Beispielstruktur: ``` Parent agent: - nutzt starkes Modell - entscheidet Architektur und finale Änderungen Subagent: - nutzt günstiges Modell - sucht relevante Dateien - fasst Testfehler zusammen - liefert kurze Ergebnisliste zurück ``` Dadurch sieht das teure Modell nur destillierte Ergebnisse statt roher Logs und kompletter Suchläufe. Die autonomen Schleifenmuster im [Zielbefehl über Codex und Claude Code](http://apidog.com/blog/goal-command-codex-claude-code-autonomous-agents?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) zeigen, wie solche Delegation strukturiert werden kann. Auch bei Plänen mit Nutzungslimits hilft Routing. Sie verbrauchen Ihr Premium-Kontingent nicht für triviale Aufgaben. Die [Erhöhung des wöchentlichen Limits von Claude Code](http://apidog.com/blog/claude-code-weekly-limits-50-percent-increase-july-2026?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) hilft zwar, ersetzt aber kein sinnvolles Routing. ## Tool-Ausgabe und Abruf kürzen Tool-Ausgabe ist ein versteckter Kostentreiber. Jeder Befehl, den der Agent ausführt, erzeugt Text. Dieser Text landet im Kontext und wird später erneut gesendet. Typische Probleme: - `npm install` mit tausenden Zeilen - ausführliche Testlogs - vollständige Stacktraces - große `git diff` -Ausgaben - generierte Lockfile-Diffs - komplette Dateien statt relevanter Ausschnitte ### 1. Befehle leise machen Statt: ``` npm test ``` besser: ``` npm test --silent -- --reporter=dot ``` Statt: ``` npm install ``` besser: ``` npm install --silent --no-audit --no-fund ``` Für Python: ``` pytest -q ``` Für gezielte Tests: ``` pytest tests/payments/test_retry.py -q ``` ### 2. Ausgabe filtern, bevor der Agent sie sieht Nur die letzten relevanten Zeilen: ``` pytest -q 2>&1 | tail -n 30 ``` Nur Fehlerzeilen: ``` npm test 2>&1 | grep -E "(FAIL|✗|Error)" | head -n 20 ``` Nur Diff-Statistik: ``` git diff --stat ``` Nur Diff für relevante Dateien: ``` git diff -- src/payments/retry.ts src/payments/retry.test.ts ``` Das ist oft ausreichend, damit der Agent den nächsten Schritt ableitet. ### 3. Gezielte Dateiabschnitte lesen Eine komplette Datei mit 1.500 Zeilen zu lesen, nur um eine Funktion zu ändern, ist teuer. Besserer Prompt: ``` Find the retry function in src/payments/retry.ts. Read only the function and its surrounding tests. Do not read the entire file unless necessary. ``` Oder manuell vorbereiten: ``` grep -n "function retry" src/payments/retry.ts sed -n '80,160p' src/payments/retry.ts ``` Das reduziert einen möglichen 18.000-Token-Lesevorgang auf wenige hundert Tokens. ### 4. RAG- und Suchabrufe begrenzen Wenn Ihr Agent Dokumente oder Code-Chunks abruft, begrenzen Sie: - Anzahl der Chunks - Chunk-Größe - Suchbereich - Dateitypen - Verzeichnisse Besser: ``` Return the top 8 chunks, max 250 tokens each, only from docs/api and src/payments. ``` Schlechter: ``` Search the whole repo and include all relevant context. ``` Sie zahlen für jeden abgerufenen Token, auch wenn das Modell ihn nicht nutzt. ## Kosten pro Lauf messen Ohne Messung optimieren Sie blind. Ziel ist nicht nur eine niedrigere Monatsrechnung, sondern Kosten pro repräsentativer Aufgabe. Wenn Sie die API direkt verwenden, speichern Sie das `usage` -Objekt: ``` u = response.usage INPUT_RATE = 3.00 / 1_000_000 OUTPUT_RATE = 15.00 / 1_000_000 CACHE_READ = 0.30 / 1_000_000 CACHE_WRITE = 3.75 / 1_000_000 cost = ( u.input_tokens * INPUT_RATE + u.output_tokens * OUTPUT_RATE + u.cache_read_input_tokens * CACHE_READ + u.cache_creation_input_tokens * CACHE_WRITE ) print( f"run cost ≈ ${cost:.4f} " f"(in={u.input_tokens} " f"out={u.output_tokens} " f"cache_read={u.cache_read_input_tokens})" ) ``` Die Preise sind nur Platzhalter. Ersetzen Sie sie durch die aktuellen Preise Ihres Modells. Wenn Sie eine Agenten-CLI nutzen: ``` claude /cost ``` Zusätzlich sinnvoll: ``` # separater API-Key pro Projekt oder Agent # dadurch sehen Sie Kosten in der Anbieter-Konsole sauber getrennt ``` Oder ein Wrapper-Skript: ``` bash #!/usr/bin/env bash TASK="$1" START="$(date -Iseconds)" claude "$TASK" END="$(date -Iseconds)" echo "$START,$END,$TASK" >> agent-runs.csv ``` Noch besser ist ein Log mit: - Aufgabe - Modell - Input-Tokens - Output-Tokens - Cache-Reads - Cache-Writes - geschätzten Kosten - Git-Branch oder PR-ID Messen Sie dann wiederkehrende Aufgaben: ``` Kosten pro täglichem Refactoring-Lauf Kosten pro PR-Review Kosten pro Testfix Kosten pro API-Dokumentationsupdate ``` Wenn Sie Caching aktivieren oder Unteraufgaben routen, sollte sich diese Zahl sichtbar ändern. Falls nicht, optimieren Sie an der falschen Stelle. ## Taktikvergleich | Taktik | Typische Token-Einsparung | Aufwand | |---|---|---| | Arbeitssatz eingrenzen | 30–60% Input pro Lauf | Gering | | Kurze, stabile Speicherdatei | 5–15% pro Runde | Gering | `/compact` oder `/clear` zwischen Aufgaben | 40–80% bei langen Sitzungen | Gering | | Prompt-Caching für stabile Präfixe | ~90% für gecachten Kontext | Mittel | | Modell-Routing | 50–80% bei gerouteten Unteraufgaben | Mittel | | Leise oder gefilterte Tool-Ausgabe | 20–50% bei tool-intensiven Läufen | Gering | | Gezieltes Lesen statt ganzer Dateien | 70–95% bei großen Dateien | Gering | | Begrenzter Abrufbereich | 30–60% bei RAG-intensiven Agenten | Mittel | | Kostenmessung pro Lauf | 0% direkt, ermöglicht Optimierung | Gering | Die Werte sind illustrativ. Einsparungen addieren sich nicht linear, sondern wirken häufig multiplikativ. ## Praktische Checkliste Wenden Sie diese Reihenfolge an: - **Repo-Ignorierregeln setzen**`node_modules/` `dist/` `coverage/` - generierte Dateien - große Fixtures - `CLAUDE.md` kürzen- nur Build-, Test- und Stilregeln - keine langen Dokumentationen - auf Detaildocs verlinken - **Prompts enger schreiben**- konkrete Dateien nennen - Zielverhalten beschreiben - unnötige Exploration verbieten - **Tool-Ausgaben filtern**`--silent` `-q` `tail` `grep` `git diff --stat` - **Sitzungen trennen**- eine Aufgabe pro Session - danach `/compact` oder`/clear` - **Günstige Modelle als Default**- einfache Aufgaben günstig routen - teures Modell bewusst eskalieren - **Prompt-Caching aktivieren**- stabile Präfixe byte-stabil halten - volatile Inhalte nach hinten schieben - **Kosten messen**- pro Lauf - pro Aufgabe - pro Projekt oder Agent ## Fazit Token-Kosten von CLI-Agenten sind oft selbst verursacht: zu viel Kontext, zu laute Tools, zu lange Sitzungen und zu teure Modelle für einfache Aufgaben. Die wirksamsten Maßnahmen sind einfach: - Dateien und Aufgaben eng eingrenzen - Speicherdateien schlank halten - Tool-Ausgaben kürzen - lange Konversationen kompaktieren - einfache Arbeit an günstigere Modelle geben - stabile Präfixe cachen - Kosten pro Lauf messen Starten Sie mit den Maßnahmen mit geringem Aufwand. Sie kosten fast nichts, wirken aber bei jedem Agentenlauf. Danach bringen Prompt-Caching und Modell-Routing die Einsparungen auf ein Niveau, das sich im Team-Budget sichtbar bemerkbar macht.