KI-News · Werkzeuge

Token sparen in Claude Code:
Was wirklich hilft.

21. Juli 2026 · aktualisiert 26. Juli 2026 · Lesezeit ca. 14 Minuten

Drei Werkzeuge versprechen, die Token-Rechnung von KI-Coding-Agenten drastisch zu senken: Ponytail, Graphify und RTK. Ich habe alle drei an demselben produktiven Projekt nachgemessen — und dabei nicht nur die Ersparnis notiert, sondern auch, was jedes von ihnen kostet.

Wer Claude Code oder einen vergleichbaren Agenten produktiv einsetzt, merkt schnell: Der limitierende Faktor ist selten das Können des Modells, sondern das Kontextfenster. Jede gelesene Datei, jede Testausgabe, jedes git status landet im Kontext und wird bezahlt. Bei einem Team von fünf Entwicklern summiert sich das zu einem echten Posten.

Rund um dieses Problem ist ein kleines Ökosystem entstanden. Drei Werkzeuge werden gerade besonders häufig genannt. Sie setzen an völlig unterschiedlichen Stellen an — und genau das ist der interessante Teil.

Die drei Ansätze im Vergleich

Sie schließen sich gegenseitig nicht aus. Man kann alle drei parallel betreiben, weil sie an verschiedenen Stellen der Kette greifen.

Ponytail — weniger Code schreiben lassen

Und hier wird es interessant. Ein unabhängiger Test zeigt ein sehr uneinheitliches Bild:

• Große, offene Aufgabe („bau ein Admin-Dashboard“): 101 statt 464 Zeilen Code, 3,6K statt 8,4K Tokens. Deutlicher Gewinn.
• Kleine, scharf umrissene Aufgaben (User-Auth, CSV-Export, Rate Limiting): kein Vorteil bis Nachteil. Bei der Auth-Aufgabe waren es 6K statt 2,3K Tokens — also mehr als ohne, weil der Agent zusätzlich über die Ponytail-Leiter nachdenkt.

Ein anderer Test auf einem echten FastAPI-/React-Projekt kommt auf 54 % weniger Code bei 22 % Token- und 20 % Kostenersparnis. Beides ist plausibel und widerspricht sich nicht: Ponytail wirkt gegen Over-Engineering. Wo es nichts zu over-engineeren gibt, ist der Denkaufwand reiner Zusatz.

Nachgemessen: die Leiter an einer echten Aufgabe

Die Aufgabe an PlantWiz lautete: „CSV-Export der Pflanzliste." Ein typisch knapp formuliertes Ticket. Ich habe es bewusst so gewählt, dass die Leiter nichts geschenkt bekommt: Es gab im Projekt keinerlei CSV-Code, keine passende Bibliothek, nichts zum Wiederverwenden. Ponytail konnte hier nur kürzen, nicht streichen. Dann zweimal umgesetzt — einmal geradeheraus, einmal mit der Leiter.

Die Variante ohne Leiter baute, was ein gründlicher Entwickler eben baut: eine Typdatei mit Optionsobjekt, einen RFC-4180-Serialisierer, eine Spaltendefinition mit zehn wählbaren Feldern, ein Composable mit localStorage-Persistenz, ein Modal mit Spaltenauswahl, Trennzeichen- und Datumsoptionen samt Live-Vorschau — plus 103 Zeilen Tests. Nichts davon ist falsch. Es ist nur nichts davon angefordert worden.

Die Variante mit Leiter landete auf Sprosse 4 (native Plattformfunktion?): ein Blob, ein Anker-Element, fertig — keine Bibliothek. 44 Zeilen in einem Composable, ein Knopf neben dem bestehenden PDF-Export, ein Test für das Einzige, was hier wirklich knifflig ist: das Quoting von Semikola und Anführungszeichen. Die Formel-Entschärfung gegen CSV-Injection blieb drin — Ponytail nimmt ausdrücklich Sicherheitsmaßnahmen von der Kürzung aus.

Der Preis: die Leiter kostet auch, wenn sie nichts findet

Dazu ein zweiter Punkt, der sich schlecht beziffern lässt: Die gekürzte Variante ist ärmer. Kein Trennzeichen-Wechsel, keine Spaltenauswahl. Wenn übermorgen jemand nach einem Komma-Export fragt, wird nachgebaut — und dieser Nachbau kostet erneut Tokens. Ponytail wettet darauf, dass die Frage meistens nicht kommt. Diese Wette ist in der Regel richtig, aber sie ist eine Wette, keine Ersparnis.

Fazit: Empfehlenswert, mit realistischer Erwartung — rechnen Sie mit rund 40 % netto bei offen formulierten Aufgaben und mit null bis leicht negativ bei präzisen Tickets. Der Gewinn, den keine Token-Statistik zeigt, liegt ohnehin woanders: 465 Zeilen, die nie geschrieben wurden, müssen auch nie gewartet, gelesen oder migriert werden.

Graphify — den Code als Graph statt als Textwüste

Zwei Einschränkungen, die man kennen muss:

• Der Graph ist ein abgeleitetes Artefakt. Er veraltet, sobald sich der Code ändert. Ein Index, der hinter der Realität herhinkt, ist schlimmer als keiner — er führt den Agenten mit Überzeugung in die Irre.
• Der Doku-Teil kostet API-Aufrufe. Die Code-Analyse läuft komplett lokal. Die semantische Extraktion aus PDFs und Dokumentation braucht einen API-Key und damit Geld. Bei einem großen Dokumentenbestand ist das ein laufender Posten.

Nachgemessen: Orientierung im Adminbereich

Der Indexbau an PlantWiz dauerte 38 Sekunden für 258 Codedateien und ergab 2.014 Knoten, 2.994 Kanten und 179 Cluster. Die graph.json ist 1,7 MB groß — die liest der Agent nie am Stück, er fragt sie ab.

Dieselbe Aufgabe, dieselbe Frage: Welche Dateien muss ich anfassen, und wie hängen sie zusammen? Einmal klassisch mit Suchen und Lesen, einmal über den Graphen:

Der Grund für den Abstand ist banal: AdminView.vue hat 1.323 Zeilen und 51 KB. Wer wissen will, was darin steckt, liest im Normalfall alles. graphify explain liefert für 1.948 Bytes die Liste aller 58 enthaltenen Symbole mit Zeilennummern — genug, um zu entscheiden, welche 40 Zeilen man wirklich braucht.

Der Preis: zwei Lücken, die man kennen muss

Dazu zwei kleinere Baustellen aus dem Protokoll: 27 .sql-Dateien trugen nichts bei, weil tree_sitter_sql nicht mitinstalliert wird — bei PlantWiz mit einer 4 MB großen init.sql ist das das halbe Datenmodell. Und 11 weitere Dateien ergaben schlicht null Knoten.

Fazit: Empfehlenswert, sobald ein Projekt über den Prototypen hinaus ist — aber mit realistischer Erwartung. Graphify ist ein exzellentes Werkzeug zum Ausleuchten einer Datei, die man bereits im Visier hat, und ein mittelmäßiges zum Finden dieser Datei. In der Praxis heißt das: erst grep auf Dateinamen, dann explain — die Kombination war in meiner Messung der günstigste Weg. Den Index-Neubau gehören in den Pre-Commit-Hook oder die CI, sonst führt der Graph den Agenten irgendwann selbstbewusst in die Irre.

RTK — die Werkzeugausgabe eindampfen

Warum RTK am schnellsten wirkt: Es ist die einzige der drei Maßnahmen, die keine Verhaltensänderung verlangt und kein Artefakt pflegen lässt. Einmal einrichten, danach wirkt es im Hintergrund. Und es greift genau dort, wo in der Praxis am meisten Kontext verbrannt wird: bei Testausgaben und Buildlogs.

Nachgemessen: 47 Kommandos im Alltag

Herstellerangaben sind Herstellerangaben. Ich habe RTK 0.43 deshalb an einem produktiven Projekt gegengeprüft — PlantWiz, eine Vue-3-Anwendung mit Node-Backend, rund 45.000 Zeilen TypeScript und Vue, 327 Unit-Tests. Jeweils dasselbe Kommando einmal roh und einmal durch RTK, gemessen in Bytes der Ausgabe:

Über alle im Projekt abgesetzten Kommandos hinweg meldet rtk gain nach 47 Aufrufen 149.000 eingesparte Tokens bei 167.300 Roh-Tokens — 89,1 %. Die Herstellerangabe von 60–90 % ist also nicht geschönt, sie ist realistisch.

Drei Beobachtungen dazu. Erstens: Der Gewinn ist extrem ungleich verteilt. Ein einziger git diff machte 106.000 der 149.000 gesparten Tokens aus. Zweitens: Bei Kommandos, die von Haus aus kompakt sind — git log --oneline, ein Grep mit wenigen Treffern — passiert schlicht nichts, RTK reicht sie unverändert durch. Kein Schaden, aber auch kein Nutzen. Drittens: Der Effekt ist am größten bei genau den Ausgaben, die man ohnehin am seltensten komplett liest. Testrunner und Buildlogs sind zu 95 % Formatierung.

Der Preis: Information geht verloren

Drei Stellen, an denen mir das in der Messung konkret aufgefallen ist:

• Der Testlauf schrumpft auf eine Zeile. Aus 79 Zeilen Vitest-Ausgabe wird PASS (327) FAIL (0). Weg sind dabei nicht nur Farbcodes: In der Rohausgabe stand ein stderr-Block aus einem Test, der einen Netzwerkfehler protokolliert. Harmlos in diesem Fall — aber ein Agent, der nur die eine Zeile sieht, kann echte Warnungen, Deprecation-Hinweise oder auffällig langsame Tests nicht mehr bemerken.
• Der Diff verliert seine Struktur. Die komprimierte Fassung wirft Hunk-Header und teilweise die +/−-Marker weg; übrig bleiben Codezeilen ohne erkennbare Zuordnung, und am Ende steht [530 more lines]. Für einen Überblick reicht das. Für die Frage „wurde diese Zeile hinzugefügt oder entfernt?“ nicht mehr.
• Metadaten fallen ersatzlos weg. rtk ls liefert Namen und Größen, aber keine Änderungsdaten und keine Rechte. Wer wissen will, welche Datei zuletzt angefasst wurde, muss erneut nachfragen — und zahlt den zweiten Aufruf.

Der Umgang damit ist einfach, man muss ihn nur kennen: RTK ist richtig für den Normalfall und falsch für die Fehlersuche. Wenn ein Test rot ist und der Agent im Kreis läuft, gehört die Rohausgabe her — rtk proxy <kommando> umgeht den Filter. Wer das nicht tut, riskiert das schlechteste aller Ergebnisse: einen Agenten, der auf Basis einer Zusammenfassung rät und dabei mehr Tokens verbrennt, als der Filter je gespart hat.

Was ohne Zusatzwerkzeug mehr bringt

Bevor Sie drei Tools installieren: Die größten Hebel kosten nichts und sind reine Disziplin.

1. Den Kontext bewusst leeren

Der teuerste Fehler ist die Endlos-Session. Jede Nachricht schleppt den gesamten bisherigen Verlauf mit — die Kosten wachsen quadratisch, nicht linear. Eine abgeschlossene Aufgabe gehört mit /clear beendet, nicht mit „und jetzt noch schnell…“ verlängert. Eine Session, eine Aufgabe.

2. Unbenutzte MCP-Server abschalten

Jeder verbundene MCP-Server schreibt seine kompletten Werkzeugdefinitionen in den Kontext — bei jedem Aufruf, ob genutzt oder nicht. Drei Server, die Sie diese Woche nicht brauchen, sind ein permanenter Grundverbrauch. Das ist stille, dauerhafte Verschwendung, die kaum jemand prüft.

3. Suchen delegieren

Wenn eine Frage bedeutet, zwanzig Dateien zu durchsuchen, gehört das in einen Subagenten. Der hat sein eigenes Kontextfenster, wühlt sich durch — und liefert nur das Ergebnis zurück, nicht die zwanzig Dateien. Die Suchtrümmer landen nie in Ihrer Hauptsession.

4. Das passende Modell wählen

Nicht jede Aufgabe braucht das stärkste Modell. Umbenennungen, Formatierungen, einfache Textänderungen erledigt ein kleineres Modell zu einem Bruchteil der Kosten. Die Kunst ist, den Wechsel zur Gewohnheit zu machen.

5. Erst planen, dann bauen

Der Plan-Modus wirkt wie ein Umweg, ist aber oft der kürzere Weg. Ein Agent, der in die falsche Richtung losläuft und zurückgebaut werden muss, kostet ein Vielfaches der Tokens, die eine Abstimmung vorher gekostet hätte.

6. Die Projektanweisungen kurz halten

Die CLAUDE.md wird bei jeder Anfrage mitgeladen. Was dort steht, zahlen Sie tausendfach. Sie ist kein Handbuch, sondern ein Merkzettel — alles Ausführliche gehört in separate Dateien, die bei Bedarf gelesen werden.

Was ich davon empfehlen würde

Alle drei. Sie greifen an verschiedenen Stellen der Kette an, behindern sich nicht gegenseitig und sparen jeweils Tokens, die die anderen beiden nicht anfassen. Die Reihenfolge unten ist keine Auswahl, sondern eine Einführungsreihenfolge — sortiert nach dem Verhältnis von Aufwand zu Wirkung:

1. Erst die Disziplin — Sessions kurz halten, MCP-Server ausmisten, CLAUDE.md zusammenstreichen. Kostet nichts, wirkt sofort.
2. Dann RTK — einmal einrichten, wirkt danach unsichtbar im Hintergrund. In meiner Messung 89,1 % Ersparnis über 47 Kommandos. Merken Sie sich rtk proxy für die Fehlersuche.
3. Dann Ponytail — eine Skill-Datei, in fünf Minuten installiert. In meiner Messung 82 % weniger Code, nach Abzug der Skill-Kosten netto 43 % weniger Tokens. Bei präzise geschnittenen Tickets erwarten Sie nichts davon.
4. Dann Graphify — der aufwendigste der drei, weil ein Index gebaut und aktuell gehalten werden will. 96 % gespart beim Ausleuchten einer bekannten Datei, aber schwach beim Suchen und blind an der HTTP-Grenze. Automatisieren Sie den Index-Neubau, sonst führt der Graph den Agenten irgendwann selbstbewusst in die Irre.

Eine Beobachtung über alle drei Messungen hinweg: Die großen Zahlen entstehen immer an einer einzigen Stelle. Bei RTK war es ein git diff, der 106.000 der 149.000 gesparten Tokens ausmachte. Bei Graphify eine 51-KB-Datei, die man sonst komplett gelesen hätte. Bei Ponytail ein Optionsmodal, das niemand bestellt hatte. Der Rest plätschert im einstelligen Prozentbereich. Wer diese Werkzeuge einführt und dann gleichmäßige Einsparung über alle Operationen erwartet, wird enttäuscht — es sind Ausreißerfänger, keine Grundlastsenker.

Und rechnen Sie brutto gegen netto. Zwei der drei Werkzeuge kosten selbst Kontext: Ponytail rund 1.700 Tokens pro Codeaufgabe, Graphify jede Abfrage, die daneben greift. Nur bei RTK ist die Bruttozahl auch die Nettozahl. Bei Ponytail schrumpfen −80 % brutto auf −43 % netto — immer noch ein Gewinn, aber eben nicht der, der auf der Verpackung steht.

Und der ehrlichste Rat zum Schluss: Messen Sie, bevor Sie optimieren. Die meisten Teams, die über Token-Kosten klagen, haben ein Prozessproblem und kein Werkzeugproblem — zu vage Aufgabenstellungen, zu lange Sessions, zu wenig Struktur im Repository. Kein Tool repariert das.