Token-Effizienz bei KI-Coding-Assistenten: 10 Strategien zur Reduzierung von Kosten und Kontext

KI-Coding-Assistenten können Repositories durchsuchen, mehrere Dateien verändern, Tests ausführen und auf Fehler reagieren. Diese Fähigkeit bringt jedoch eine weniger sichtbare Ressource mit sich: den Modellkontext, der bei jedem Schritt verarbeitet wird. Je länger eine Sitzung läuft, desto mehr Dateien, Kommandoausgaben, Tool-Definitionen und frühere Nachrichten können erneut an das Modell übermittelt werden. Dadurch kann eine scheinbar kleine Coding-Aufgabe teuer, langsam und für den Assistenten zunehmend schwieriger zu verarbeiten werden.

Token-Effizienz bedeutet daher nicht einfach, kürzere Prompts zu schreiben. Es geht vielmehr darum, einem Assistenten für die jeweils anstehende Entscheidung den kleinstmöglichen ausreichenden Kontext bereitzustellen und gleichzeitig alle Informationen zu erhalten, die für ein korrektes und überprüfbares Ergebnis notwendig sind.

Die Auswirkungen sind längst nicht mehr nur theoretischer Natur. Im Jahr 2026 hatte Uber bereits im April – also nach nur vier Monaten – sein gesamtes jährliches KI-Budget ausgeschöpft, nachdem sich die Einführung von Claude Code schneller als von den Finanzmodellen erwartet auf rund 5.000 Entwickler ausgeweitet hatte. Die monatlichen Kosten pro Entwickler lagen im Durchschnitt bei 150–250 US-Dollar, während Power User Spitzenwerte von 500–2.000 US-Dollar erreichten (Janakiram, 2026). Amazon berichtete über ein vergleichbares Muster: Eine interne Claude-Sonnet-Implementierung zum Abgleich von Produktangeboten kostete 1,8 Millionen US-Dollar und lag damit 860 % über dem ursprünglichen Budget. Die Überschreitung blieb fast fünf Monate lang unbemerkt. Zwei weitere interne Projekte überschritten ihr Budget separat um 541.000 bzw. 134.000 US-Dollar (Udinmwen, 2026). Beide Fälle haben dieselbe Ursache: Token-basierte, agentische Coding-Tools verhalten sich nicht wie Software mit einer pauschalen Lizenzgebühr. Unkontrolliertes Kontextwachstum kann daher aus alltäglicher Entwicklungsarbeit eine unkontrolliert steigende Rechnung machen, bevor jemand dies bemerkt.

Dieser Artikel zeigt praktische Maßnahmen für Entwickler und Platform-Teams, die sich vor allem auf die offiziellen Empfehlungen von GitHub Copilot und Claude Code stützen. Zusätzlich wird ein wachsendes Ökosystem von Tools für Repository-Indexierung, selektive Abfragen, Output-Komprimierung und kompakte Datendarstellung bewertet.

Was verbraucht Tokens in einem KI-Coding-Workflow?

Eine Modellanfrage kann deutlich mehr enthalten als die letzte Anweisung des Entwicklers. Je nach Assistent können dazu Konversationsverlauf, ausgewählte Quelldateien, Repository-Anweisungen, Tool-Definitionen, Terminalausgaben, Diffs, Testergebnisse, abgerufene Dokumentation sowie frühere Pläne oder Ergebnisse des Assistenten gehören. Auch generierter Code und Erklärungen erzeugen Output-Tokens.

Coding-Workloads sind besonders kontextintensiv, weil Agenten häufig einen Zyklus aus Planen, Suchen, Lesen, Bearbeiten, Testen und Korrigieren wiederholen. Jeder Schritt kann neue Informationen hinzufügen oder bereits vorhandenen Kontext erneut übertragen. Große Dateien, ausführliche Logs, breit angelegte Repository-Scans und erfolglose Versuche können schnell einen Großteil der eigentlich relevanten Informationen in einer Sitzung verdrängen.

Das Ziel besteht deshalb nicht darin, Tokens um jeden Preis zu minimieren. Zu wenig Kontext kann zu fehlerhaften Änderungen, übersehenen Abhängigkeiten und zusätzlichen Korrekturschleifen führen.

Die relevante Optimierungsgröße lautet vielmehr:

Tokens pro erfolgreich abgeschlossener und validierter Aufgabe.

Zehn Maßnahmen mit dem größten Effekt

Die folgenden Maßnahmen sind nach ihrem Hebel sortiert. Die ersten Punkte beeinflussen nahezu jeden Schritt einer Agentensitzung und zahlen sich deshalb bei fast jeder Aufgabe aus. Die letzten Maßnahmen sind eher situationsabhängige Stellschrauben, die sinnvoll werden, sobald die grundlegenden Prinzipien umgesetzt sind.

1. Präzise und klar abgegrenzte Prompts schreiben

Eine vage Anfrage führt häufig zu einer breiten Suche und wiederholten Interpretationsversuchen. Ein besserer Prompt definiert Ziel, Grenzen, Akzeptanzkriterien und relevante Ausgangspunkte.

Vermeiden- vage und keine klare Eingrenzung:

Bevorzugen- Ziel, Grenzen und Akzeptanzkriterien:

Dasselbe Prinzip gilt bei der Behebung eines fehlschlagenden Tests.

Vermeiden- kein Ausgangspunkt und keine Eingrenzung: 

Bevorzugen- Fehler, Umfang und Verifizierung werden benannt: 

Dieser Prompt ist zwar länger, reduziert aber den Gesamtverbrauch, weil er unnötige Exploration und Korrekturen verhindert. Indem ein korrektes Ergebnis mit weniger Interaktionen erreicht wird, verkürzt sich gleichzeitig die Zeit bis zu einer funktionierenden Änderung.

Nimm nur Informationen auf, die die Entscheidungen des Assistenten tatsächlich verändern. Bevorzuge Dateipfade, Symbole, fehlschlagende Tests, Diffs und exakte Fehlermeldungen gegenüber einer langen Beschreibung.

2. Das Modell und den Reasoning-Aufwand an die Aufgabe anpassen

Für jede Anfrage das leistungsfähigste Reasoning-Modell zu verwenden, ist selten kosteneffizient. GitHub empfiehlt Reasoning-Modelle für Architekturentscheidungen, komplexes Debugging und Systemdesign. Modelle der mittleren Leistungsklasse eignen sich für die Umsetzung eines klaren Plans, während leichtere Modelle für Routine-Refactorings, Formatierung oder Dokumentation eingesetzt werden können.

Die automatische Modellauswahl von GitHub Copilot kann Anfragen ebenfalls entsprechend ihren Anforderungen weiterleiten und vermeiden, dass während einer cachebaren Aufgabe das Modell gewechselt wird.

Eine praktische Team-Richtlinie könnte folgendermaßen aussehen:

• Leichtgewichtiges Modell:
  Formatierung, Umbenennungen, Boilerplate, Dokumentation und einfache Tests
• Allgemeines Modell:
  Abgegrenzte Feature-Implementierung, vertraute Refactorings und routinemäßiges Debugging
• Reasoning-Modell:
  Architekturentscheidungen, unbekannte Fehlerbilder, Änderungen über mehrere Systeme hinweg und sicherheitskritische Analysen

Die Modellgröße ist allerdings nur eine Stellschraube. Ebenso wichtig kann die Einstellung für den Reasoning-Aufwand sein. Sie bestimmt, wie viel Rechenleistung ein Modell während der Inferenz vor seiner Antwort aufwendet.

Coding-Tools verwenden häufig standardmäßig eine mittlere Einstellung, während veröffentlichte Benchmarks mit hohen Einstellungen wie high, xhigh oder max arbeiten können. Ein Modell, das bei mittlerem Aufwand schwach erscheint, kann daher deutlich leistungsfähiger werden, wenn es länger über eine Aufgabe nachdenken darf – und das teilweise zu geringeren Inferenzkosten als bei einem Wechsel auf ein größeres Modell.

Die hier diskutierten Werte und Index-Scores basieren auf dem Coding Agents Leaderboard von Artificial Analysis.

In der GPT-5.6-Familie kann beispielsweise eine höhere Reasoning-Stufe des leichtgewichtigen Modells Luna ein nahezu führendes Ergebnis zu deutlich geringeren Kosten liefern, als direkt auf das größere Sol-Modell mit standardmäßig mittlerem Reasoning zu wechseln.

GPT-5.6 Luna mit maximalem Reasoning erreicht im dargestellten Benchmark einen Indexwert von 59 bei geschätzten Kosten von 0,31 US-Dollar pro Aufgabe. Das liegt nur zwei Punkte unter GPT-5.6 Sol mit mittlerem Reasoning (2,99 US-Dollar), während die geschätzten Kosten pro Aufgabe um rund 90 % sinken. Luna mit x-high Reasoning kostet 0,25 US-Dollar – rund 92 % weniger als Sol mit mittlerem Reasoning –, erreicht allerdings einen um sechs Punkte niedrigeren Indexwert. Für viele Aufgaben ist das kleinere Modell mit höherem Reasoning-Aufwand daher die wirtschaftlichere Wahl, sofern eine Leistung nahe am Spitzenbereich ausreicht.

Die Einsparung geht allerdings zulasten der Bearbeitungszeit: Im selben Benchmark steigt die durchschnittliche Agentenzeit pro Aufgabe von etwa 5,2 Minuten bei Sol mit mittlerem Reasoning auf etwa 8 Minuten bei Luna mit maximalem Reasoning. Wenn ein Entwickler auf das Ergebnis warten muss, können diese zusätzlichen 2,8 Minuten pro Aufgabe wichtiger sein als die niedrigeren Kosten.

Bevor du auf ein größeres Modell wechselst, teste das leichtgewichtige Modell mit hohem oder maximalem Reasoning an repräsentativen Aufgaben.

Vergleiche dabei nicht nur Benchmark-Scores, sondern auch:

• Kosten pro erfolgreich abgeschlossener Aufgabe
• Latenz
• Anzahl der Korrekturschleifen

Setze die Reasoning-Stufe vor Beginn der Sitzung, damit das Prompt-Caching nicht beeinträchtigt wird.

Hinweis zur Interpretation: Die Prozentwerte wurden aus den dargestellten Benchmark-Werten berechnet und auf ganze Prozent gerundet. Benchmark-Ergebnisse hängen vom Agent-Harness, Aufgabensatz, Reasoning-Level und den zugrunde gelegten Preisen ab. Bevor ein unternehmensweiter Standard definiert wird, sollte die Auswahl anhand des eigenen Repositories und der eigenen Workloads validiert werden.

3. Trennen der Planung und Ausführung

Bei komplexen Aufgaben sollte man der Versuchung widerstehen, Recherche, Planung und Implementierung in einer einzigen, durchgängigen Sitzung durchzuführen. GitHub empfiehlt, die Arbeit in klar voneinander getrennte Phasen aufzuteilen: Verwenden Sie ein leistungsfähiges Reasoning-Modell, um die Codebasis zu untersuchen und einen prägnanten, überprüfbaren Plan zu erstellen, lassen Sie einen Entwickler diesen Plan freigeben oder anpassen und setzen Sie ihn anschließend mit einem kostengünstigeren Modell um – idealerweise in einer neuen Sitzung, die mit dem freigegebenen Plan statt mit der vollständigen Planungshistorie beginnt.

Der wesentliche Grund für die Aufteilung dieser Phasen liegt darin, dass Recherche und Planung naturgemäß kontextintensiv sind. Die Untersuchung eines Repositorys bringt Dateien, Suchergebnisse, verworfene Optionen und Sackgassen in den Kontext, und jeder dieser Tokens wird bei jedem weiteren Turn erneut übertragen, wenn die Implementierung in derselben Unterhaltung fortgesetzt wird. Der Start der Umsetzung in einer neuen Sitzung verwirft diesen angesammelten Kontext und führt nur den fertigen Plan wieder ein. Dadurch arbeitet das Implementierungsmodell mit dem kleinsten ausreichenden Kontext statt mit einem Protokoll darüber, wie der Plan entstanden ist.

Ein schlankerer Kontext führt außerdem zu einer zuverlässigeren Umsetzung. Wenn die explorative Planung nicht mehr um die Aufmerksamkeit des Modells konkurriert, ist es wesentlich unwahrscheinlicher, dass der Agent überholte Überlegungen erneut aufgreift, einen vom Plan bereits verworfenen Ansatz wieder aufnimmt oder vom vereinbarten Umfang abweicht; jede Phase arbeitet nur mit dem, was sie benötigt, um die nächste richtige Entscheidung zu treffen. Dieses Vorgehen bietet daher drei sich verstärkende Vorteile:

1. Teures Reasoning wird nur dort eingesetzt, wo es einen Mehrwert bietet, während die Umsetzung auf einem kostengünstigeren Modell läuft.
2. Der Ausführungsagent erhält ein kleineres, gezielt zusammengestelltes Kontextpaket und setzt den Plan dadurch präziser um.
3. Die menschliche Prüfung findet statt, bevor umfangreiche Änderungen am Repository zusätzlichen Tokenverbrauch verursachen.

Der Start einer neuen Sitzung für die Umsetzung verwirft zwar den Prompt-Cache der Planungssitzung, in der Praxis sind die dadurch entstehenden Kosten jedoch selten relevant: Der Wechsel von einem Reasoning-Modell zu einem günstigeren Ausführungsmodell würde diesen Cache ohnehin ungültig machen (siehe Praxis 6), und der kleine, stabile Plan baut schnell einen neuen Cache auf, der über die vielen Turns der Implementierung hinweg wiederverwendet wird.

4. Wo immer möglich deterministische Workflows verwenden

KI-Agenten arbeiten probabilistisch: Dieselbe Anweisung kann zu unterschiedlichen Plänen und Ergebnissen führen, und kleine Fehler können sich in einem mehrstufigen Workflow verstärken.

Deshalb sollte man das Modell nicht mit einer Aufgabe beschäftigen, die zuverlässig durch ein vorhandenes deterministisches Tool erledigt werden kann.

Wiederkehrende Operationen wie:

• Ausführen einer Testsuite
• Formatieren
• Linting
• Scannen von Abhängigkeiten
• Abrufen von AWS-Logs
• Sammeln diagnostischer Informationen

sollten einmal als Skripte oder Standardbefehle implementiert und anschließend vom Agenten aufgerufen werden.

Diese Skripte sollten als wiederverwendbare Skills mit einer klar abgegrenzten Schnittstelle, dokumentierten Eingaben und vorhersehbaren Ausgaben bereitgestellt werden.

Der Agent muss dann lediglich die passende Fähigkeit auswählen und aufrufen, anstatt wiederholt über Versuch und Irrtum Befehle zu generieren.

Anthropics Skill für das Testen von Webanwendungen zeigt dieses Muster: Gebündelte Hilfsskripte werden wie Black Boxes behandelt und direkt aufgerufen. Dadurch muss ihr Quellcode nicht unnötig in den Kontext geladen werden, während gleichzeitig eine reproduzierbare Möglichkeit zur Verwaltung von Servern und zur Ausführung von Tests entsteht.

Unit- und Integrationstests

Sie überprüfen, ob die erzeugten Änderungen das erwartete Verhalten erfüllen und Regressionen verhindern, bevor der Agent auf einem fehlerhaften Ergebnis weiterarbeitet.

Formatter und Linter

Sie erzwingen Struktur und Konsistenz automatisch, anstatt Modellinteraktionen für Stilkorrekturen zu verbrauchen.

Sicherheits- und Policy-Scans

Sie erkennen Secrets, verwundbare Abhängigkeiten, unsichere Patterns und unzulässige Änderungen anhand klarer Pass/Fail-Signale.

Betriebsskripte

Sie rufen Logs ab, starten lokale Services, reproduzieren Fehler oder sammeln Diagnosedaten in einer stabilen, vorab getesteten Form.

Diese Prüfungen sollten lokal für schnelles Feedback und anschließend erneut in CI/CD als Gate ausgeführt werden, das darüber entscheidet, ob eine Änderung ausgeliefert wird.

So entsteht ein enger Feedback-Loop:

Agent ändert Code → deterministische Prüfung bewertet Änderung → Agent erhält Pass/Fail-Ergebnis → nächster Schritt

Ein Test oder Scan kostet wenige Sekunden. Ihn wegzulassen und den Agenten raten zu lassen, kostet dagegen häufig mehr: Ein falscher Ansatz kann mehrere weitere Korrekturen auslösen, die jeweils zusätzliche Logs und Diffs in den Kontext einbringen.

Praktische Regel

• Das Modell sollte für Beurteilung, Ambiguität und Anpassung eingesetzt werden. Skripte, Tests, Hooks und CI/CD sollten wiederholbare Ausführung und Durchsetzung übernehmen.

Wenn ein Workflow einen eindeutigen Exit-Code oder ein strukturiertes Ergebnis liefern kann, sollte dieses Signal bevorzugt werden, anstatt das Modell selbst entscheiden zu lassen, ob seine eigene Arbeit korrekt ist.

5. Lange Gespräche schlank halten: Zum richtigen Zeitpunkt komprimieren oder neu starten

Lange Gespräche bauen eine Art Kontextverschuldung auf: fehlgeschlagene Ansätze, überholte Anforderungen, wiederholte Logs und Annahmen, die nicht mehr gelten. Die Kostenempfehlungen von Claude betonen Kontextmanagement, Modellauswahl, Extended-Thinking-Einstellungen und Preprocessing-Hooks als wichtige Stellschrauben zur Reduzierung des Verbrauchs.

Die /usage-Ansicht von Claude Code kann die aktuelle Nutzung beispielsweise Bereichen wie Skills, Subagents, Plugins und MCP-Servern zuordnen und macht dadurch Kontextwachstum besser sichtbar.

Das Wachstum lässt sich anhand eines Beispiels verdeutlichen.Hier bezeichnet ein „Turn“ eine weitergeführte Interaktion innerhalb derselben Unterhaltung ohne Compaction¹ oder Neustart. Eine tatsächlich neue Unterhaltung würde den vollständigen bisherigen Verlauf nicht übernehmen.

Die folgenden Zahlen sind illustrative Schätzungen und keine Telemetriedaten eines Anbieters. Jede Schätzung repräsentiert den vollständigen Arbeitskontext, der für diesen Turn übertragen wird – einschließlich gespeicherter Historie, Anweisungen, ausgewählter Dateien, Tool-Ausgaben, Diffs und Testergebnisse.

Abbildung 3. Beispiel für das Wachstum des Kontexts über acht TurnsDer Kontext erreicht vor Turn 7 zunächst 175.000 Tokens, bevor die Unterhaltung komprimiert wird. In Turn 8 sinkt er auf 45.000 Tokens. Die groben Kosten basieren auf dem angegebenen GPT-5.6-Sol-Preis von 5 US-Dollar pro 1 Mio. Input-Tokens und 30 US-Dollar pro 1 Mio. Output-Tokens bei einer festen Schätzung von 2.000 Output-Tokens pro Turn. Cached Input und Cache-Write-Gebühren sind ausgeschlossen; der tatsächliche Output variiert.

„Hinzugefügt“ bezeichnet den initialen Kontext für Turn 1, den neu eingeführten Kontext bis Turn 7 sowie die nach der Komprimierung in Turn 8 dargestellte Kontextreduktion.Die groben Kosten kombinieren nicht gecachten Input mit 5 US-Dollar pro 1 Mio. Tokens und eine feste Output-Schätzung von 2.000 Tokens zu 30 US-Dollar pro 1 Mio. Tokens. Cached Input und Cache-Write-Kosten sind ausgeschlossen.Der kumulative Input summiert den vollständigen Arbeitskontext, der in jedem Turn übertragen wird, nicht nur den sichtbaren Prompt. Der komprimierte Übergabekontext ist bewusst deutlich kleiner als das ursprüngliche Gespräch, sodass Turn 8 mit 45k statt mit 175k Tokens startet.

Wann sollte komprimiert oder neu gestartet werden?

Komprimiere den Kontext nach einem bedeutenden Meilenstein, beispielsweise nach der Diagnose und vor der Implementierung.

Starte eine neue Unterhaltung, wenn sich das Ziel ändert.

Übertrage dabei eine strukturierte Übergabe mit:

• Ziel und Umfang
• bereits getroffenen Entscheidungen
• beteiligten Dateien und Symbolen
• aktuellem Teststatus
• verbleibenden Aufgaben und Risiken

Beim Komprimieren sollte außerdem eine kurze Anweisung angegeben werden, welche Informationen in der Zusammenfassung erhalten bleiben müssen.

Beispielsweise priorisiert:

/compact Focus on code samples and API usage

diese Details gegenüber einer allgemeinen Zusammenfassung.

Die Anweisung sollte an die jeweilige Aufgabe angepasst werden – beispielsweise mit Fokus auf:

• Architekturentscheidungen
• fehlschlagende Testausgaben
• geänderte Dateien
• ungelöste Risiken
• exakte API-Verträge

Individuelle Compaction-Anweisungen machen den reduzierten Kontext nützlicher und verringern die Wahrscheinlichkeit, dass fehlende Informationen später erneut recherchiert werden müssen.

Compaction funktioniert erst, nachdem eine Sitzung ausreichend Gesprächshistorie aufgebaut hat. In einer neuen Sitzung meldet Claude Code andernfalls:

„Not enough messages to compact.“

6. Den Prompt-Cache während einer Coding-Sitzung erhalten

Prompt-Caching ermöglicht es einem KI-Modell, Teile eines bereits verarbeiteten Kontexts wiederzuverwenden. Dazu können Systemanweisungen, Dateiinhalte, Gesprächshistorie und Tool-Definitionen gehören.

Das ist insbesondere in agentischen Coding-Workflows wertvoll, weil derselbe große Kontext über viele Turns hinweg wiederholt übertragen wird.

Laut GitHub werden gecachte Tokens typischerweise mit etwa 10 % des normalen Input-Token-Preises berechnet. Der genaue Preis hängt vom jeweiligen Modell ab.

Entscheidend ist zu verstehen, wie der Cache entscheidet, was wiederverwendet werden kann.

Der Claude-Code-Leitfaden beschreibt den Mechanismus als Prefix Matching: Das Modell verarbeitet die vollständige Anfrage bei jedem Turn erneut, während der Cache den Anfang – also das Prefix – jeder Anfrage mit bereits zuvor verarbeitetem Inhalt abgleicht.

Der Abgleich ist exakt. Eine Änderung irgendwo im Prefix führt dazu, dass alles dahinter neu berechnet werden muss. Es gibt kein Caching auf Datei- oder Segmentebene.

Um davon zu profitieren, bauen Coding-Assistenten Anfragen typischerweise so auf, dass der stabilste Inhalt zuerst kommt:

1. System-Prompt und Tool-Definitionen
2. Projektkontext wie AGENTS.md
3. wachsende Konversation

Eine Änderung weiter unten lässt dadurch alles davor gecacht.

Eine Änderung in der Konversationsebene lässt die vorherigen Ebenen gecacht, während eine Änderung am System-Prompt oder Toolset alles dahinter invalidiert.

Bei einem normalen Turn ist der gecachte Prefix praktisch die vollständige vorherige Anfrage; nur der letzte Austausch ist neu. Genau diese Annahme wird in der folgenden Schätzung verwendet.

Abbildung 4. Ein beispielhaftes Szenario mit acht Turns und Caching. Turn 1 etabliert den Cache. Die Turns 2–7 behandeln den gesamten vorherigen Turn als gecacht zu 10 % des Preises von 5 $ pro Million Input-Tokens, während neue Eingaben weiterhin zum vollen Preis berechnet werden. Turn 8 folgt auf eine Komprimierung, wobei 8k des übergebenen Kontexts zu 10 % gecacht werden und 37k des neuen Kontexts zum vollen Input-Preis berechnet werden. Jeder Turn beinhaltet dieselbe feste Schätzung von 2.000 Output-Tokens. Dies ist eine Schätzung für die vollständige Anfrage und keine Provider-Telemetrie; Cache-Berechtigung, Gebühren für das Schreiben in den Cache und die tatsächliche Output-Menge variieren je nach Modell und Anbieter.

Unter diesen Annahmen reduziert Caching die Schätzung für die acht Turns von etwa 4,03 auf 1,79 US-Dollar. Das entspricht einer Ersparnis von 2,24 US-Dollar bzw. 56 %. Die Einsparung pro Turn steigt von etwa 38 % in Turn 2 auf 82 % in Turn 7, weil der gecachte Anteil von 20.000 auf 170.000 Tokens wächst, während nur der neu hinzugefügte Input zum vollen Input-Preis berechnet wird. Turn 8 profitiert nach der Komprimierung noch geringfügig vom Cache: 8.000 Tokens der komprimierten Übergabe bleiben gecacht. Dadurch sinkt der geschätzte Preis von 0,29 auf 0,25 US-Dollar. Caching macht jedoch nicht die gesamte Anfrage 90 % günstiger. Output, neuer Input und Kontext nach einer Komprimierung verursachen weiterhin Kosten. Wiederholter Kontext wird lediglich deutlich günstiger, solange der Cache gültig bleibt.

Wie bleibt der Cache erhalten?

Um vom Caching zu profitieren, sollte die Sitzungs-Konfiguration stabil bleiben.

Lege vor Beginn der Aufgabe fest:

• Modell
• Reasoning-Level
• Kontextgröße
• aktivierte Tools

und ändere diese Einstellungen nicht während einer zusammenhängenden Aufgabe.

Der Claude-Code-Leitfaden fasst dieses Prinzip sinngemäß zusammen:

Modell und Reasoning-Level am Anfang der Sitzung auswählen und Compaction für natürliche Übergänge zwischen Aufgaben reservieren.

Je weniger Änderungen während einer Aufgabe vorgenommen werden, desto höher ist die Cache-Trefferrate.

Diese Aktionen invalidieren den Cache

Modell wechseln:
Ein Modell kann den Cache eines anderen Modells nicht wiederverwenden. Das Modell ist Bestandteil des Cache-Schlüssels.

Reasoning oder Tool-Einstellungen ändern:
Eine Änderung des Reasoning-Levels oder der Kontextgröße führt zu einer erneuten Berechnung der gesamten Anfrage. Auch das Hinzufügen, Entfernen, Verbinden oder Trennen von Tools, MCP-Servern oder Plugins kann den System-Prompt verändern und damit den Prefix-Cache invalidieren.

Den Assistenten während der Sitzung aktualisieren:
Eine neue Version verändert typischerweise System-Prompt oder Tool-Definitionen. Der nächste Turn muss den Cache daher möglicherweise vollständig neu aufbauen.

Diese Aktionen halten den Cache dagegen warm

Mehrere häufige Aktionen können den Cache erhalten, da sie lediglich am Ende der Konversation angehängt werden:

• Skills und Commands aufrufen
• eine Terminal-Zusammenfassung erzeugen
• den Berechtigungsmodus ändern
• Repository-Dateien bearbeiten

Wenn man einen Sackgassenpfad verlassen möchte, ist es besser, auf einen früheren Turn zurückzuspringen als zu komprimieren. Ein Zurückspringen schneidet die Unterhaltung auf einen bereits gecachten Prefix zurück, während Compaction einen neuen Prefix erzeugt.

Auch die Zeit spielt eine Rolle

Gecachte Prefixes laufen nach einer gewissen Inaktivitätszeit ab.

GitHub gibt an, dass Caches bei OpenAI-Modellen nach 24 Stunden Inaktivität und bei den meisten anderen Modellen nach einer Stunde ablaufen.

Der Claude-Code-Leitfaden beschreibt standardmäßig fünf Minuten, die bei einem Claude-Abonnement automatisch auf eine Stunde verlängert werden können.

Nach einer längeren Pause muss der erste Turn die vollständige Historie möglicherweise erneut ohne Cache verarbeiten. In diesem Fall ist es sinnvoller, eine neue Sitzung zu starten oder /compact auszuführen, sodass der Kontext aus einer kompakten Zusammenfassung statt aus der vollständigen Gesprächshistorie neu aufgebaut wird.

Schließlich sollte überprüft werden, ob Caching tatsächlich funktioniert.

Coding-Assistenten zeigen typischerweise:

• Cache-Read-Token
• Cache-Write-Token

Eine hohe Read-to-Write-Ratio deutet auf einen stabilen Prefix hin. Bleiben die Write-Werte dagegen Turn für Turn hoch, verändert sich wahrscheinlich etwas im Prefix.

7. AGENTS.md kurz, kuratiert und in menschlicher Verantwortung halten

Persistente Anweisungsdateien und Tool-Definitionen verbrauchen Kontext, bevor der Assistent mit der eigentlichen Aufgabe beginnt. AGENTS.md und CLAUDE.md sind im Wesentlichen dasselbe Artefakt: eine Anweisungsdatei, die der Assistent automatisch lädt, unabhängig davon, ob sie auf Benutzer-, Organisations-, Repository- oder Unterverzeichnisebene abgelegt ist. AGENTS.md ist die tool-agnostische Konvention, die von vielen Assistenten übernommen wurde, während Claude Code eine Datei namens CLAUDE.md liest; im weiteren Verlauf dieses Abschnitts wird AGENTS.md stellvertretend für jede solche Datei verwendet. Diese Dateien sind wertvoll, wenn sie nicht offensichtliche Coding-Konventionen, verbindliche Befehle, architektonische Grenzen und Qualitätsanforderungen festhalten. Allerdings konkurriert jede global geladene Anweisung mit dem Code und den Informationen, die für die aktuelle Entscheidung benötigt werden. Die Datei wird zu Beginn jeder Sitzung automatisch geladen, sodass jedes darin enthaltene detaillierte Verfahren auch bei Aufgaben im Basiskontext verbleibt, bei denen dieses Verfahren irrelevant ist.

Generieren Sie AGENTS.md nicht automatisch und übernehmen Sie das Ergebnis nicht einfach als Repository-Richtlinie. Gloaguen et al. stellten fest, dass von LLMs generierte Repository-Kontextdateien die Aufgabenerfüllung nicht verbesserten und dass Kontextdateien die Inferenzkosten im Durchschnitt um mehr als 20 % erhöhten. Die Agenten befolgten die hinzugefügten Anweisungen im Allgemeinen, aber die zusätzlichen Anforderungen führten zu einer umfassenderen Dateierkundung, zusätzlichen Tests und mehr Tool-Aufrufen; insbesondere Repository-Übersichten erwiesen sich als wenig hilfreich. Automatisch generierte Anweisungen können daher plausibel wirkenden Kontext hinzufügen, der Routineaufgaben teurer oder schwieriger macht, ohne Informationen beizusteuern, die der Agent nicht selbst hätte ermitteln können.

Behandeln Sie die Datei stattdessen als ein kleines, von Menschen gepflegtes Konfigurationsartefakt. Maintainer sollten nur minimale, verifizierte Anforderungen hinzufügen, die sowohl nicht standardmäßig als auch allgemein anwendbar sind. Dazu gehören beispielsweise die verbindlichen Build- und Testbefehle, ungewöhnliche Entscheidungen beim Paketmanager, architektonische Grenzen, die nicht überschritten werden dürfen, sowie verpflichtende Validierungs- oder Sicherheitsregeln. Lassen Sie generierte Verzeichnisbäume, Repository-Zusammenfassungen, erkennbare Technologie-Beschreibungen, doppelte README-Inhalte und Stilregeln weg, die bereits von Formatierern oder Lintern durchgesetzt werden. Überprüfen Sie jede vorgeschlagene Zeile in einem Pull Request, messen Sie, ob sie repräsentative Aufgaben verbessert, und entfernen Sie Anweisungen, die nachweislich keinen Einfluss auf korrektes Verhalten haben. Beschränken Sie dauerhaft geladene Anweisungsdateien auf Vorgaben, die breit und konsistent gelten. Verschieben Sie aufgabenspezifische Verfahren – beispielsweise Pull-Request-Reviews, Release-Prozesse, Datenbankmigrationen oder Incident Response – in Skills, die nur geladen werden, wenn sie relevant sind. Ersetzen Sie beispielsweise ein 100-zeiliges Migrationsverfahren in AGENTS.md durch einen dedizierten Datenbankmigrations-Skill, der bei Bedarf aufgerufen werden kann.

Wenden Sie dasselbe Prinzip auf Tools an. Große Tool-Sammlungen – beispielsweise ein vollständiger MCP-Server mit zahlreichen verfügbaren Operationen – fügen bei jeder Anfrage Tool-Beschreibungen zum Kontext hinzu. Aktivieren Sie daher, soweit es der Workflow erlaubt, nur die MCP-Server, Plugins und Tool-Sets, die für die aktuelle Aufgabe benötigt werden. Eine fokussierte Tool-Konfiguration reduziert den Basiskontext, schränkt die Auswahlmöglichkeiten des Assistenten ein und verringert das Risiko irrelevanter Tool-Aufrufe.

Beide Maßnahmen folgen demselben Prinzip der schrittweisen Offenlegung: Halten Sie die dauerhaft aktive Basis klein und stellen Sie detaillierte Verfahren und Tool-Definitionen erst in dem Moment bereit, in dem eine Aufgabe sie benötigt.

Als praktische Faustregel gilt: Halten Sie AGENTS.md bei weniger als etwa 200 Zeilen und überprüfen Sie den persistenten Kontext wie produktiven Code. Entfernen Sie doppelte Anweisungen, veraltete Ausnahmen, nicht verwendete Tools und Text, der das Verhalten nicht beeinflusst. Stellen Sie sich vor Beginn einer Aufgabe zwei Fragen: „Muss der Assistent dies bei jeder Anfrage wissen?“ und „Muss dieses Tool für diese Aufgabe verfügbar sein?“ Falls nicht, laden Sie es bei Bedarf oder lassen Sie es deaktiviert.

8. Verwenden Sie Englisch als Standardsprache

Natürlichsprachlicher Text wird in Tokens umgewandelt, bevor er von einem Modell verarbeitet wird, und gleichwertige Anweisungen benötigen nicht zwangsläufig in jeder Sprache dieselbe Anzahl an Tokens. Da viele Modell-Tokenisierer und Trainingskorpora stark auf Englisch optimiert sind, stellt Englisch häufig gebräuchliche Wörter und technische Ausdrücke kompakter dar als Sprachen wie Deutsch oder Japanisch. Für Coding-Assistenten macht dies Englisch zu einer sinnvollen Standardsprache für persistente Anweisungen, die wiederholt gesendet werden – insbesondere für AGENTS.md, Skill-Dateien, Repository-Konventionen und wiederverwendbare Prompt-Vorlagen.

Die potenzielle Einsparung lässt sich anhand derselben Git-Anweisung veranschaulichen, die in vier Sprachen übersetzt wurde. Gemessen mit dem OpenAI-Tokenizer für GPT-5.x- und O-Series-Modelle wächst dieselbe Anweisung gegenüber der englischen Ausgangsbasis auf etwa 76 % mehr Tokens im Deutschen und auf mehr als doppelt so viele Tokens im Japanischen, wie die folgende Tabelle zeigt. Die genauen Verhältnisse hängen vom Modell und Tokenizer ab, aber wiederholte Unterschiede sind relevant, wenn dieselben Anweisungsdateien in jede Anfrage einbezogen werden.

Beispiel-Prompt, der für den Vergleich verwendet wurde: „Überprüfe meinen aktuellen Git-Branch, identifiziere alle Commits, die noch nicht in main gemergt wurden, schlage eine optimale interaktive Rebase-Strategie vor, um eine saubere Commit-Historie zu erstellen, und generiere die dafür erforderlichen exakten Git-Befehle.“

Language	Token count	Additional tokens vs. English	Relative token use
English		Baseline	1.00×
Chinese		+17 (+59%)	1.59×
German		+22 (+76%)	1.76×
Japanese		+33 (+114%)	2.14×

Illustrative tokenizer check: counts were measured for the translated prompt shown above with the OpenAI tokenizer setting for GPT-5.x and O-series models.

In der Praxis sollten wiederverwendbare technische Anweisungen auf Englisch standardisiert werden, wenn das Team sie zuverlässig überprüfen kann. Englisch sollte jedoch nicht in jeder Interaktion erzwungen werden. Der Kontext eines Coding-Assistenten besteht häufig aus Quellcode, Diffs, Tool-Definitionen und Command-Ausgaben, sodass ein einmaliger Prompt möglicherweise nur einen kleinen Anteil der Gesamtkosten ausmacht. Ein klarer, präziser Prompt in der stärksten Sprache des Entwicklers ist einem vagen oder fehleranfälligen englischen Prompt vorzuziehen, der zusätzliche Suchen, Korrekturen oder fehlgeschlagene Versuche verursacht.

Dasselbe Prinzip gilt direkt innerhalb von Quelldateien. Docstrings, Kommentare und Inline-Erklärungen werden von Coding-Assistenten häufig wiederholt gelesen, wenn sie Funktionen untersuchen, Zusammenfassungen erstellen, Tests generieren oder nach einem fehlgeschlagenen Versuch dieselbe Datei erneut bearbeiten. Ein deutscher Docstring kann für ein deutschsprachiges Team vollkommen verständlich sein, kann jedoch vermeidbaren Token-Overhead erzeugen und den umgebenden technischen Kontext für den Assistenten weniger einheitlich machen.

Vermeiden Sie dieses Muster in gemeinsam genutztem Repository-Code:

Bevorzugen Sie die englische Version:

Das wirkt zunächst harmlos, wird jedoch teuer, wenn dieselbe Datei während eines agentischen Workflows immer wieder geladen wird. Der Assistent kann diese Funktion während der Planung einer Änderung lesen, sie beim Bearbeiten zugehöriger Tests erneut untersuchen, sie nach einem fehlgeschlagenen Testlauf wieder aufrufen und sie später in Zusammenfassungen oder Diffs einbeziehen. Jede Wiederholung sendet die nicht-englische natürlichsprachliche Erklärung erneut und vergrößert den Kontext, ohne zusätzliche Informationen hinzuzufügen, die nicht kompakter und konsistenter auf Englisch ausgedrückt werden könnten.

Englische Docstrings schaffen außerdem eine einheitlichere gemeinsame Grundlage für gemischte Teams, Open-Source-Konventionen, externe Bibliotheken und Coding-Assistenten, die stark mit englischem technischem Material trainiert wurden. Die Empfehlung lautet nicht, die Kommunikation in lokalen Sprachen zu verbieten, sondern wiederverwendbaren technischen Kontext – Docstrings, Kommentare, Repository-Anweisungen, Beispiele und Prompt-Vorlagen – auf Englisch zu halten, wenn diese Dateien voraussichtlich wiederholt von KI-Tools verarbeitet werden.

Diese Empfehlung ist ein Standard, keine feste Regel, und es gibt gute Gründe, davon abzuweichen. Das zugrunde liegende Ziel ist eine einheitliche Sprache für den wiederholt verwendeten technischen Kontext in einem Repository oder einer Sitzung – Englisch ist für die meisten Tokenizer einfach die tokeneffizienteste Wahl und kein Selbstzweck. Wenn ein stärkerer Grund für eine andere Sprache spricht, sollte diesem gefolgt werden: Ein Team, das Englisch schlecht versteht, wird in seiner eigenen Sprache besseren Code erstellen und überprüfen; Software für einen bestimmten Markt benötigt möglicherweise Bezeichner und Dokumentation in der jeweiligen Landessprache; und einige Kunden oder regulierte Bereiche schreiben ausdrücklich vor, dass Code und Docstrings in einer bestimmten Sprache verfasst werden. In diesen Fällen überwiegen die Vorteile für Verständnis und Korrektheit den moderaten Token-Overhead. Was selten sinnvoll ist, ist eine dritte Sprache, die niemand im Team gut beherrscht – das Konfigurieren des Harness, der Anweisungen und der Prompts in einer Sprache, die man nicht fließend spricht, obwohl Englisch besser geeignet wäre, verursacht zusätzliche Kosten ohne entsprechenden Nutzen.

9. Verwenden Sie C++ und JSON nicht- zumindest nicht ausschließlich wegen der Token-Effizienz

Die Überschrift ist bewusst nicht ganz ernst gemeint: Niemand sollte ein geeignetes C++-System allein deshalb neu schreiben, um Prompt-Tokens zu sparen. Die Auswahl einer Programmiersprache muss weiterhin von Laufzeitanforderungen, Ökosystem, Sicherheit, Wartbarkeit, Teamkompetenz und Kompatibilität bestimmt werden. Dennoch bilden Programmiersprachen dieselbe Logik mit unterschiedlichen Mengen an Syntax, Boilerplate und Typinformationen ab. Daher kann die primäre Sprache eines Repositorys beeinflussen, wie viel Quellcode in das Kontextfenster eines Agenten passt. Martin Aldersons explorativer Vergleich vergleichbarer Rosetta-Code-Lösungen zeigte erhebliche Unterschiede zwischen Programmiersprachen, wobei prägnante dynamische und funktionale Sprachen im Allgemeinen weniger Tokens verwendeten als ausführlichere Low-Level-Sprachen. Die Analyse ist als Indikator nützlich, nicht als Benchmark für die Auswahl einer Programmiersprache: Der Autor weist ausdrücklich auf Einschränkungen und Verzerrungen des Datensatzes hin, und die Anzahl der Tokens sagt für sich genommen nichts über Korrektheit, Performance, Sicherheit, die Qualität des generierten Codes oder die Anzahl der Iterationen aus, die ein Agent benötigt. Betrachten Sie Spracheffizienz bei der Auswahl einer neuen Technologie als sekundären Faktor – nicht als Grund, eine etablierte C++-Codebasis aufzugeben.

Die folgende Tabelle gibt das Ranking des Token Calculators auf Grundlage der durchschnittlichen Token-Anzahl für Aufgaben im Rosetta-Stil wieder; die ursprüngliche Bewertungsspalte wurde weggelassen.

Quelle: Token Calculator, „Most Token-Efficient Languages for LLMs, Ranked & Priced“, basierend auf Programmieraufgaben im Rosetta-Stil und Messungen mit Tokenizern. Die ursprüngliche Bewertungsspalte wurde hier weggelassen.

Token-Effizienz ist außerdem nicht dasselbe wie Gesamteffizienz. Eine Sprache oder Darstellung, die für ein LLM kompakt ist, kann dennoch ineffizient sein, sobald der generierte oder gewartete Code ausgeführt wird. Insbesondere bei KI-Workloads zeigen Marini et al., dass die Wahl der Programmiersprache den Energieverbrauch erheblich beeinflussen kann: In ihrem kontrollierten GREENS-2025-Experiment mit C++, Java, Python, MATLAB und R verbrauchten kompilierte und semi-kompilierte Sprachen im Allgemeinen weniger Energie als interpretierte Sprachen, die in einigen Fällen bis zu 54-mal mehr Energie benötigten. Sie betonen außerdem, dass die energieeffizienteste Wahl vom Algorithmus, der Trainings- oder Inferenzphase, der Implementierung und den Entwicklungsabwägungen abhängt. Daher sollten Entscheidungen über Sprache und Format für KI-gestützte Software Tokenkosten, Wartbarkeit, Eignung des Ökosystems, Laufzeitperformance und Energieeffizienz gemeinsam berücksichtigen. Bei strukturierten Daten, die an ein Modell gesendet werden, lässt sich das Format leichter ändern. Token-Oriented Object Notation (TOON) ist eine verlustfreie Darstellung des JSON-Datenmodells, die für LLM-Eingaben entwickelt wurde. Sie ersetzt wiederholte Schlüssel, geschweifte Klammern und Anführungszeichen durch Einrückungen und tabellarische Zeilen. Ihr stärkster Anwendungsfall ist ein einheitliches Array von Objekten; tief verschachtelte oder unregelmäßige Daten können JSON begünstigen. Daher sollten vor der Einführung repräsentative Payloads gemessen werden.

Beispiel-Payload in JSON:

Entsprechende Payload in TOON: 

In dieser TOON-Kodierung deklariert die Kopfzeile users[2]{id,name,role}: das Array einmal: [2] gibt die Anzahl der folgenden Zeilen an, und {id,name,role} benennt die Felder, die von jedem Benutzer gemeinsam verwendet werden. Jeder Benutzer reduziert sich anschließend auf eine einzige durch Kommas getrennte Zeile, anstatt die Schlüssel, geschweiften Klammern und Anführungszeichen zu wiederholen. Die TOON-Dokumentation berichtet für diese Art von Beispieldaten von etwa 117 Tokens in JSON gegenüber etwa 66 in TOON. Die Einsparungen hängen jedoch von Datenstruktur, Formatierung und Tokenizer ab.

So kompakt dies auch aussieht: Behalten Sie JSON als Standard bei und behandeln Sie TOON als eng begrenzte Ausnahme. JSON wird universell unterstützt, dominiert die Trainingsdaten von Modellen und lässt sich mit Standardwerkzeugen wie jq leicht untersuchen und filtern. Verwenden Sie TOON für große, einheitliche Arrays, bei denen repräsentative Benchmarks tatsächliche Token-Einsparungen ohne Genauigkeitsverlust zeigen – und verwenden Sie es nur an der LLM-Grenze, nicht als kanonisches Anwendungs- oder API-Format.

Für Coding-Agenten ist dies eher der Normalfall als die Ausnahme: Sie arbeiten in langen Sitzungen mit vielen Interaktionen. Eine Benchmark-Studie zu tokenoptimierten Formaten in agentischen Systemen stellte fest, dass TOON die Token-Anzahl um bis zu 18 % reduzierte, jedoch mit einem Genauigkeitsverlust von ungefähr 9 Prozentpunkten. Außerdem „verliert [TOON] in Multi-Turn-Szenarien weiter an Genauigkeit, in denen Parsing-Fehler zu zusätzlichen Iterationen beim Reasoning führen und die Einsparungen pro Aufruf aufzehren“ (Kutschka & Geiger, 2026). Die Studie kommt zu dem Schluss, dass TOON „nicht sicher als Standard“ sei. Dieselbe Studie bewertete TRON (Token Reduced Object Notation) als sicherer – mit bis zu 27 % weniger Tokens bei einer Genauigkeit innerhalb von 14 Punkten von JSON –, wenn der Workload viele strukturell ähnliche Tool-Schemata enthält. Messen Sie die Gesamtkosten und Aufgabenqualität für Ihren eigenen Workload, bevor Sie eines der beiden Formate einsetzen.

10. Verwenden Sie dedizierte Tools zur sorgfältigen Optimierung der Token-Nutzung

Selbst gut abgegrenzte Coding-Aufgaben können erheblichen Kontext erzeugen: Testergebnisse, Compiler-Ausgaben, Repository-Scans, Logs, strukturierte Payloads, Tool-Antworten und frühere Nachrichten. Ein wachsendes Ökosystem von Tools verspricht, diesen Overhead zu reduzieren, indem die Informationen, die das Modell erreichen, komprimiert, gefiltert oder neu strukturiert werden. Beispiele sind RTK, Headroom, Context Mode, Caveman, Ponytail, Repository-Graph-Tools, Symbolindizes und kompakte Datenformate.

Diese Tools können nützlich sein, sollten jedoch nicht als universeller Schalter zum Kostensparen betrachtet werden. Beworbene Einsparungen von 33–99 % pro komprimierter Payload können technisch real sein, während der Einfluss auf die Gesamtrechnung gering bleibt. In vollständigen Coding-Agent-Sitzungen befinden sich viele Tokens außerhalb des komprimierbaren Bereichs: Repository-Kontext, Tool-Definitionen, Prompt-Cache-Lese- und Schreibvorgänge, Gesprächshistorie, Reasoning-Overhead, generierter Code und Dateidiffs.

Deshalb werden die Auswirkungen von Komprimierung im Laufe der Zeit häufig abgeschwächt. In einer kurzen, output-lastigen Sitzung kann ein Tool, das ausführliche Logs oder Gesprächsfüllmaterial entfernt, einen sichtbaren Anteil der Tokens einsparen. In einer langen Coding-Sitzung können diese Einsparungen jedoch durch wiederholtes Abrufen, Cache-Aktivitäten, angesammelte Historie sowie nicht komprimierbaren Code oder Tool-Traffic wieder aufgezehrt werden. Einen nützlichen unabhängigen Datenpunkt liefert eine Untersuchung von etwa 500 Claude-Code-Sitzungen mit 614 Millionen verarbeiteten Tokens und Basiskosten von ungefähr 926 US-Dollar. Obwohl einige Tools große Einsparungen pro Payload beworben hatten, war der gemessene Einfluss auf die tatsächlichen Gesamtkosten moderat: Headroom sparte 2,8 %, RTK 0,5 %, Caveman 0,4 % und alle Tools zusammen 3,7 %. Die Schlussfolgerung lautet nicht, dass diese Tools nutzlos sind, sondern dass hohe beworbene Kompressionsraten selten direkt in entsprechend hohe Einsparungen bei den Gesamtkosten übersetzt werden.

Aktuelle JetBrains-Benchmarks erzählen in einer kontrollierten Umgebung dieselbe Geschichte. Caveman bewarb eine Reduzierung der Output-Tokens um 65 %, tatsächlich gemessene Einsparungen bei realistischen Claude-Code-Agent-Aufgaben lagen jedoch bei 8,5 %. Ein separater JetBrains-RTK-Benchmark stellte fest, dass die von RTK beworbene Token-Reduktion von 60–90 % nicht zu niedrigeren Gesamtkosten des Agenten führte: Bei realen Claude-Code-Agent-Aufgaben war RTK bei niedrigem Reasoning-Aufwand 7,6 % teurer und zeigte bei hohem Reasoning-Aufwand keinen messbaren Kostenunterschied, während die Aufgabenqualität unverändert blieb. Ponytail war vielversprechender, weil es versucht, die unnötige Codegenerierung selbst zu reduzieren: JetBrains maß etwa 15 % weniger Code, 10,3 % niedrigere Kosten und 11 % weniger Zeit – immer noch deutlich unter den beworbenen Werten. Diese Ergebnisse sind aufgabenspezifisch und hängen vom Benchmark-Harness, Modell, Repository und der Architektur des Assistenten ab.

Sicherheit und Governance verdienen besondere Aufmerksamkeit. Tools wie RTK fangen Command-Ausgaben ab oder verändern sie, bevor sie dem Modell angezeigt werden. Dadurch kann Rauschen entfernt werden, gleichzeitig können jedoch auch Informationen verloren gehen. Eine zu aggressive Filterung kann Warnungen, Stack Traces, fehlgeschlagene Prüfungen, Policy-Verstöße, Ergebnisse der Secret-Erkennung oder andere sicherheitsrelevante Signale verbergen. In regulierten oder sicherheitssensiblen Umgebungen sollten Teams Roh-Logs für die Nachvollziehbarkeit aufbewahren, Filter anhand repräsentativer Fehler testen und Ausgaben von Sicherheits- oder Compliance-Prüfungen nicht komprimieren, sofern die ursprünglichen Details nicht weiterhin verfügbar sind.

Auch diese Untersuchungen sind spezifisch für ihr jeweiliges Harness und die Architektur des Assistenten. Claude Code, GitHub Copilot, Cursor, Aider, OpenCode und andere Coding-Assistenten unterscheiden sich darin, wie sie Kontext, Tools, Caching, Repository-Zugriff und Agent-Loops verwalten. Ein Tool, das in einer Umgebung hilfreich ist, kann in einer anderen weniger Wirkung, keine Wirkung oder andere Risiken haben. Daher sollten Teams Token-Tools mit ihren eigenen Repositories, ihrer Aufgabenverteilung, ihren Sicherheitsanforderungen und ihren Quality Gates benchmarken, bevor sie sie umfassend einsetzen.

Die praktische Empfehlung ist daher vorsichtig: Verwenden Sie diese Tools gezielt für kurze, output-intensive Sitzungen oder klar identifizierte Engpässe – nicht als Ersatz für eine gute Aufgabenabgrenzung, selektives Retrieval, deterministische Workflows und sauberes Sitzungsmanagement. Die zuverlässigste Strategie besteht weiterhin darin, irrelevanten Kontext gar nicht erst in die Sitzung gelangen zu lassen.

Fazit

Tokeneffizientes Arbeiten mit AI-Coding-Assistenten ist in erster Linie ein Problem des Context Engineering – und dieselbe Disziplin, die Kosten senkt, verkürzt auch die Lieferzeit, weil ein Agent, der den kleinstmöglichen ausreichenden Kontext erhält, mit weniger Interaktionsschritten zu einem korrekten und überprüfbaren Ergebnis gelangt. Die größten Vorteile liegen an der Spitze der Liste: Jede Aufgabe präzise abgrenzen, Modell und Reasoning-Aufwand an die Aufgabe anpassen und Planung und Ausführung voneinander trennen. Workflow- und Sitzungshygiene – deterministische Prüfungen, rechtzeitige Komprimierung und ein stabiler Prompt-Cache – verstärken diese Vorteile, während kuratierte Anweisungsdateien, englische Standards, Sprach- und Formatentscheidungen sowie dedizierte Komprimierungstools sekundäre Stellhebel sind, deren beworbene Einsparungen anhand realer Repositories, Sprachen und Qualitätsanforderungen validiert werden sollten.

Die vollständige Liste der Gewohnheiten, nach Hebelwirkung geordnet:

• Schreiben Sie präzise, klar abgegrenzte Prompts, die Dateien, Symbole, fehlgeschlagene Tests und Akzeptanzkriterien benennen – keine lange Beschreibung.
• Passen Sie Modell und Reasoning-Aufwand an die Aufgabe an; testen Sie ein leichteres Modell mit hohem oder maximalem Reasoning-Aufwand, bevor Sie auf ein größeres Modell wechseln.
• Trennen Sie Planung und Ausführung: Planen Sie mit einem Reasoning-Modell und führen Sie den genehmigten Plan anschließend in einer neuen Sitzung mit einem günstigeren Modell aus.
• Lassen Sie deterministische Tools (Tests, Linter, Scans, CI) die Korrektheit beurteilen, anstatt das Modell seine eigene Arbeit überprüfen zu lassen.
• Komprimieren Sie den Kontext an Meilensteinen und starten Sie eine neue Sitzung, wenn sich das Ziel ändert. Übernehmen Sie dabei eine strukturierte Übergabe von Ziel, Entscheidungen, Dateien, Teststatus und Risiken.
• Halten Sie die Sitzungskonfiguration stabil – Modell, Reasoning-Aufwand und Tools –, damit der Prompt-Cache während einer Aufgabe aktiv bleibt.
• Halten Sie AGENTS.md kurz (~200 Zeilen), in menschlicher Verantwortung und frei von automatisch generiertem Füllmaterial.
• Halten Sie wiederholt geladenen Kontext auf Englisch – AGENTS.md, Skills, Docstrings und Prompt-Vorlagen.
• Betrachten Sie die Token-Effizienz von Programmiersprachen und Datenformaten als sekundären Faktor – beispielsweise TOON nur an der LLM-Grenze – und validieren Sie sie anhand realer Anforderungen.
• Verwenden Sie dedizierte Komprimierungs- und Retrieval-Tools selektiv und benchmarken Sie sie mit Ihren eigenen Repositories, bevor Sie sie umfassend einsetzen.

Das wichtigste Prinzip ist einfach:

Stellen Sie den kleinstmöglichen Kontext bereit, der ausreicht, um die nächste korrekte und überprüfbare Entscheidung zu treffen.

Teams, die dieses Prinzip anwenden, reduzieren sowohl Kosten als auch Latenz und machen gleichzeitig das Verhalten von Agenten leichter verständlich, überprüfbar und steuerbar.

Referenzen und weiterführende Literatur

1. Sahajmeet Kaur, TrueFoundry,“OpenCode Token Usage: How It Works and How to Optimize It,” 27 July 2026. https://www.truefoundry.com/blog/opencode-token-usage-how-it-works-and-how-to-optimize-it

2. Pochi,“Five Practical Tips to Save Token Consumption with Pochi,” publication date not stated, accessed 28 July 2026. https://docs.getpochi.com/developer-updates/reduce-token-consumption-with-pochi/

3. Aleksandar Petrov, Emanuele La Malfa, Philip H. S. Torr and Adel Bibi,“Language Model Tokenizers Introduce Unfairness Between Languages,” NeurIPS 2023. https://arxiv.org/pdf/2305.15425

4. Simiao Ren et al.,“Mythbuster: Chinese Language Is Not More Efficient Than English in Vibe Coding: A Preliminary Study on Token Cost and Problem-Solving Rate,” arXiv:2604.14210v1, 6 April 2026. https://arxiv.org/html/2604.14210v1

5. GitHub Docs,“Optimizing Your AI Usage to Maximize Efficiency and Reduce Cost,” publication date not stated, accessed 28 July 2026. Features and availability may vary by Copilot client, plan, model, and product version. https://docs.github.com/en/copilot/tutorials/optimize-ai-usage

6. RTK contributors,“RTK: High-Performance CLI Proxy,” GitHub project documentation, publication date not stated, accessed 28 July 2026. https://github.com/rtk-ai/rtk

7. Yamada Shun and contributors,“Repomix,” GitHub project documentation, publication date not stated, accessed 28 July 2026. https://github.com/yamadashy/repomix

8. Colby McHenry and contributors,“CodeGraph,” GitHub project documentation, publication date not stated, accessed 28 July 2026. https://github.com/colbymchenry/codegraph

9. DeusData and contributors,“codebase-memory-mcp,” GitHub project documentation, publication date not stated, accessed 28 July 2026. https://github.com/DeusData/codebase-memory-mcp

10. J. Gravelle and contributors,“jCodeMunch MCP,” GitHub project documentation, publication date not stated, accessed 28 July 2026. https://github.com/jgravelle/jcodemunch-mcp

11. Graphify,“Knowledge Graphs for AI Coding Assistants,” publication date not stated, accessed 28 July 2026. https://graphify.net/knowledge-graph-for-ai-coding-assistants.html

12. Headroom Labs and contributors,“Headroom,” GitHub project documentation, publication date not stated, accessed 28 July 2026. https://github.com/headroomlabs-ai/headroom

13. Johann Schopplich and contributors, “TOON: Getting Started,” TOON documentation, version 4.1.0, publication date not stated, accessed 29 July

2026. https://toonformat.dev/guide/getting-started.html

14. Context-mode contributors,“Context-Mode: Context Window Optimization for AI Coding Agents,” GitHub project documentation, publication date not stated, accessed 28 July 2026. https://github.com/mksglu/context-mode

15. Anthropic,“Manage Costs Effectively,” Claude Code documentation, publication date not stated, accessed 28 July 2026. Product behavior may vary by version. https://code.claude.com/docs/en/costs#reduce-token-usage

16. Julius Brussee and contributors,“Caveman,” GitHub project documentation, publication date not stated, accessed 28 July 2026. The stated token reduction is a project claim and is not treated as independently verified in this article. https://github.com/juliusbrussee/caveman

17. Martin Alderson,“Which Programming Languages Are Most Token-Efficient?” 8 January 2026. The author describes the analysis as exploratory rather than a scientific study. https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient/

18. The Net Revenue,“How Much Money Is It Costing You Not to Write to AI in English?” publication date not stated, accessed 28 July 2026. https://www.thenetrevenue.com/en/tokens-language-english-ai/

19. Denis Shiryaev, JetBrains,“Speaking to AI Agents like Cavemen Saves 65% of Tokens. We Test,” 6 July 2026. https://blog.jetbrains.com/ai/2026/07/speak-to-ai-agents-like-cavemen-tosave-tokens/

20. Denis Shiryaev, JetBrains,“Ponytail Skill for Claude Code: Does It Really Cut Tokens,” 28 July 2026. https://blog.jetbrains.com/ai/2026/07/ponytail-skill-claude-tested/

21. Denis Shiryaev, JetBrains,“rtk Claude Code Token Savings: A Skill Trial Benchmark,” 20 July 2026. https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/

22. CodePointer,“Cutting LLM Token Costs with RTK,” publication date not stated, accessed 29 July 2026. https://codepointer.substack.com/p/cutting-llm-token-costs-with-rtk

23. Thibaud Gloaguen, Niels Mündler, Mark Müller, Veselin Raychev and Martin Vechev, “Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?” arXiv:2602.11988v1, 12 February 2026. https://arxiv.org/html/2602.11988v1

24. Token Calculator, “Most Token-Efficient Languages for LLMs, Ranked & Priced,” publication date not stated, accessed 30 July 2026. https://tokencalculator.ai/most-token-efficient-languages-for-llms-ranked-priced/

25. Niccolò Marini, Leonardo Pampaloni, Filippo Di Martino, Roberto Verdecchia and Enrico Vicario, “Green AI: Which Programming Language Consumes the Most?” 9th International Workshop on Green and Sustainable Software (GREENS), 2025. https://robertoverdecchia.github.io/papers/GREENS\_2025.pdf

26. DietrichGebert and contributors, "Ponytail," GitHub project documentation, publication date not stated, accessed 30 July 2026. https://github.com/DietrichGebert/ponytail

27. Artificial Analysis, "AI Coding Agent Benchmarks & Leaderboard," publication date not stated, accessed 30 July 2026. https://artificialanalysis.ai/agents/coding-agents

28. Anthropic, "How Claude Code Uses Prompt Caching," Claude Code documentation, publication date not stated, accessed 30 July 2026. Product behavior may vary by version, model, and provider. https://code.claude.com/docs/en/prompt-caching

29. Janakiram MSV, Forbes, "Uber Burns Its 2026 AI Budget in Four Months on Claude Code," 17 May 2026. https://www.forbes.com/sites/janakirammsv/2026/05/17/uber-burns-its-2026-ai-budget-in-four-months-on-claude-code

30. Efosa Udinmwen, TechRadar Pro, "Amazon Admits It Accidentally Shelled Out $1.8 Million for Claude to Finish Its Menial Coding Tasks," accessed 7 August 2026. https://www.techradar.com/pro/amazon-admits-it-accidentally-shelled-out-usd1-8-million-for-claude-to-finish-menial-coding-tasks

31. Lorenz Kutschka and Bernhard C. Geiger, "Notation Matters: A Benchmark Study of Token-Optimized Formats in Agentic AI Systems," arXiv:2605.29676v2, 17 June 2026. https://arxiv.org/html/2605.29676v2

32. Timothy Huang and contributors, "TRON: Token Reduced Object Notation (JavaScript library)," GitHub project documentation, publication date not stated, accessed 7 August 2026. https://github.com/tron-format/tron-javascript