Claude Code: Tokens verstehen und beherrschen

Was?! Schon wieder?!

Ich zähle nicht mehr, wie oft ich das gesagt habe (mehr oder weniger laut), wenn ich sah, wie mein 5-Stunden-Quota von Claude Code in 2-3 Prompts aufgebraucht war.

Wenn manchmal die Größe der Codebase das zum Teil erklären konnte, zusammen mit dem schönen „Verbrauch x2“ in den Peak Hours, habe ich den Quota zuweilen früh morgens auf kleinen Codebases gesprengt. Ich bin sicher, das ist jedem mindestens einmal passiert.

Und hinter diesen gesprengten Quotas steckt immer dasselbe Problem: die Tokens. Input token / output token, warum mein Prompt plötzlich von 500 Tokens auf 20k springt.

Was genau ist also ein Token? Was erzeugt davon am meisten? Wie reduziert man den Verbrauch, um mehr aus dem Quota herauszuholen?

Unter der Haube von Claude Code

Token? Was ist das?

Ein Token ist eine Einheit, die LLMs nutzen, um Text zu lesen und zu erzeugen. Tokens sind nicht spezifisch für Claude Code — GPT und die anderen nutzen diese Einheit ebenfalls.

Wenn du Text schreibst oder Claude Text/Code lesen lässt, zerlegt es die Eingabe in Tokens. OpenAI gibt dir die Möglichkeit, zu sehen, wie sie deine Prompts in Tokens zerlegen, über ihren Tokenizer.

Achtung allerdings: die Art, in Tokens zu zerlegen, unterscheidet sich von Modell zu Modell; Claude zerlegt also nicht auf dieselbe Weise wie OpenAI zum Beispiel. Im Durchschnitt schätzt man aber, dass ein Wort 1,3 Tokens auf Englisch entspricht, und etwa 2 Tokens für ein französisches Wort.

Das gilt für einen klassischen Prompt, wenn du natürlich mit deinem Lieblings-LLM plauderst, aber beim Code ist die Tokendichte deutlich höher. Moderne Tokenizer fassen häufige Sequenzen zu einem einzigen Token zusammen — ein geläufiges englisches Wort wird oft 1 Token. Aber Code fragmentiert viel stärker: Operatoren, kurze Variablennamen, Einrückungen und symbolische Sequenzen (=>, !=, ::) erzeugen jeweils ihr eigenes Token, wo natürliche Sprache sie komprimieren würde. Ergebnis: bei gleicher Zeichenzahl verbraucht eine Codedatei durchgehend mehr Tokens als ein Satz in Prosa.

Bei einem Codeausschnitt mit weniger Zeichen als dem vorherigen Text sieht man gut, dass mehr Tokens verbraucht wurden.

Input / Output Tokens

Claude und die anderen LLMs unterscheiden Tokens in 2 Kategorien:

• Die Input tokens: die Tokens, die zum Lesen deines Prompts oder des analysierten Codes verwendet werden, zum Beispiel
• Die Output tokens: die Tokens, die zum Erzeugen der Antwort verwendet werden (der Code zum Beispiel)

Diese 2 Kategorien haben in der Regel unterschiedliche Preise: Input tokens kosten weniger als Output tokens pro Million Tokens. Bei den aktuellen Claude-4-Modellen (Sonnet, Opus) liegt das Verhältnis bei etwa 1:5 — ein Output token kostet fünfmal so viel wie ein Input token. Dieses Verhältnis kann je nach Modell variieren, aber die Größenordnung bleibt stabil. Das kommt daher, dass Text oder Code zu erzeugen deutlich mehr Ressourcen braucht als ihn zu lesen.

Um diese Kosten zu senken, nutzt Claude einen Mechanismus namens prompt caching: die Teile des Kontexts, die sich zwischen zwei Anfragen nicht ändern (System-Prompt, CLAUDE.md, Tool-Definitionen...), werden gecacht. Die stillen Injektionen beim Start profitieren stark von diesem Cache — sie werden nicht bei jedem Prompt neu berechnet.

Context window

Wir haben gesehen, was Tokens sind und wozu sie dienen, jetzt schauen wir uns an, wie Claude und die anderen LLMs ihr „Gedächtnis“ verwalten, und dieses Gedächtnis ist die context window. Die Context window steht für die Menge an Tokens, die Claude im Speicher halten kann. Für die Mehrheit der zahlenden Nutzer liegt dieses Limit bei 200K Tokens. Manche Pläne geben Zugang zu größeren Fenstern (500K auf Enterprise, 1M auf bestimmten Modellen mit aktivierten Usage Credits), aber 200K ist die Referenz, der du in den meisten Claude-Code-Sessions begegnest. Dieses Limit umfasst sowohl die Input tokens ALS AUCH die Output tokens.

Und dieses Limit kann sehr schnell erreicht sein: je mehr Claude deine Codebase lesen, Tools nutzen muss, und je mehr du dieselbe Session nutzt, desto mehr füllt sich dein Kontext. Zumal Claude bei jeder Iteration den vorherigen Kontext zurückschickt.

Zum Beispiel schreibst du einen Prompt von 200 Tokens, Claude nutzt 2000 Tokens für die Antwort (Nutzung eines Tools + Erzeugung der Antwort), dein Kontext enthält 2200 Tokens. Du bist nicht zufrieden, du schreibst einen neuen Prompt von 800 Tokens → Claude schickt die vorherigen 2200 zurück + die Tokens für die neue Antwort, und so weiter.

Und diese Context window ist nicht erweiterbar. Sobald das Limit erreicht ist, löscht Claude die ältesten Tokens und verliert damit Kontext, und genau da kann die KI beginnen, an Präzision zu verlieren, oder sogar zu halluzinieren.

Eine Context window ist auf die laufende Session begrenzt. Sobald du Claude verlässt und neu startest, geht diese Context window auf null zurück und Claude erinnert sich an nichts mehr. Eine teilweise Ausnahme: wenn du Memory-Dateien nutzt (wie CLAUDE.md), wird ihr Inhalt automatisch beim Start jeder Session wieder injiziert. Das ist keine Erinnerung im eigentlichen Sinn, weil Claude sich an nichts „erinnert“, es ist einfach persistenter Kontext, der ab dem ersten Prompt geladen wird.

Was Claude still injiziert

Wir haben die Tokens, die Context window. Wir haben gesehen, dass die Context window je nach Promptgröße, Codebase usw. sehr schnell wachsen kann. Aber hinter deinem Prompt nutzt Claude eine Menge Tokens, ohne sie dir zu zeigen. Und diese Tokens kannst du über den Befehl /context sehen. Probier es aus, tippe den Befehl in einer frischen Claude-Session. Beispiel bei mir:

Man sieht zum Beispiel bei mir, dass noch bevor ich einen Prompt geschrieben habe, schon 9% des Kontexts gefüllt sind.

Aber warum hat Claude 9% des Kontexts verbraucht, obwohl ich nichts verlangt habe? Weil Claude von Anfang an einiges injiziert:

• Dein CLAUDE.md und andere Memory-Dateien
• Die Definitionen der konfigurierten MCP tools (jeder MCP-Server fügt seine Definitionen bei jeder Session hinzu)
• Die Plugins
• Die Custom agents, die in deinem Projekt definiert sind
• Der System prompt von Claude Code selbst

Und all das kann deine Context window schnell füllen, bevor du überhaupt angefangen hast zu arbeiten. Und da wir gesagt haben, dass jeder Prompt den vorherigen Kontext zurückschickt, wird dein erster Prompt schon mindestens 18k Tokens verbrauchen (in meinem Beispiel).

Danach injiziert Claude bei jeder Anfrage zusätzlich die Dateien, die es braucht, verbraucht extra Tokens, wenn es andere Tools laden, MCPs nutzen, Befehle ausführen muss usw.

Was du in /context auch sehen wirst, ist eine Zeile Autocompact buffer — ein reservierter Bereich (~16% der Context window), den Claude Code ausschließlich für den Compaction-Prozess zurücklegt. Er ist nicht für deine Arbeit nutzbar. Anders gesagt: bei einer Context window von 200K Tokens startet dein tatsächlicher Arbeitsbereich schon um etwa 33K Tokens reduziert, noch bevor du einen ersten Prompt geschrieben hast.

Um den Schaden zu begrenzen, hat Claude ein Werkzeug.

Autocompact

Claude Code wartet nicht, bis das Limit erreicht ist, um zu handeln. Autocompact löst sich standardmäßig bei etwa 83% der Context window aus und behält eine Reserve von etwa 13.000 Tokens, um die laufende Antwort abschließen zu können, bevor kompaktioniert wird. Deshalb kann es überraschen, die Compaction „früh“ auszulösen — Claude antizipiert.

In der Praxis komprimiert Claude den Kontext und erzeugt eine Zusammenfassung der Session, kompakter, die weniger Tokens nutzt. Und genau diese Zusammenfassung wird bei jedem Prompt geschickt, statt des gesamten vorherigen Kontexts.

Das reduziert tatsächlich die Tokens, die jedes Mal geschickt werden, aber es bleibt eine von Claude erzeugte Zusammenfassung, mit den Problemen, die das mit sich bringt: nicht alles steht drin, und genau da fängt Claude an, ein bisschen in alle Richtungen zu laufen. Es kann vergessen, dass es bestimmte Dinge schon behandelt hat, eine Frage stellen, die du schon beantwortet hast, sich selbst widersprechen usw.

Es gibt auch einen Befehl /compact, den du manuell auslösen kannst, um diese Compaction durchzuführen.

Und um diesem Wachstumsproblem zu begegnen, hat Claude ein weiteres Werkzeug.

Sub-agents

Statt sich mit Kontext vollzustopfen, kann Claude Sub-agents nutzen. Das sind Untersessions, spezialisiert auf eine Aufgabe, mit eigenem Kontext. Wenn du eine Feature-Anfrage stellst, kann Claude typischerweise verschiedene spezialisierte Sub-agents anlegen, die jeweils die nötigen Tools nutzen, statt alles in der Hauptsession zu machen:

⏺ 6 Agents finished (ctrl+o to expand)
   ├─ Explore backend codebase · 23 tool uses · 104.5k tokens
   │  ⎿ Done
   ├─ Explore frontend codebase · 28 tool uses · 108.0k tokens
   │  ⎿ Done
   ├─ Write backend part · 4 tool uses · 20.0k tokens
   │  ⎿ Done
   ├─ Write frontend part · 1 tool uses · 18.6k tokens
   │  ⎿ Done
   ├─ Write unit tests · 7 tool uses · 64.0k tokens
   │  ⎿ Done
   └─ Write documentation · 24 tool uses · 52.7k tokens
      ⎿ Done

Der Vorteil: egal, wie viele Tokens jeder Sub-agent verbraucht, deine Hauptsession bekommt nur eine Zusammenfassung. Wenn deine Agents alle 150K Tokens verbrauchen, füllen sie den Kontext deiner Hauptsession nicht und schicken nur eine Zusammenfassung von ein paar Tokens.

Der Nachteil... ist, dass das deinen Quota sehr schnell sprengen kann.

Tokens sparen

Wir haben gesehen, wie leicht man den Tokenverbrauch sprengt, und damit den Quota. Auch wenn du dieses Problem auf MAX-Plänen weniger haben wirst: nicht jeder kann sich diese Pläne leisten, also muss man auf die Tokens achten.

CLAUDE.md: das Gedächtnis deines Projekts

CLAUDE.md ist DIE wichtigste Datei deines Projekts. Sie gibt Claude die Infos, die es braucht, um den Code so zu erzeugen, wie du ihn willst, sie gibt ihm die Architektur deines Projekts, deine Naming-/Git-Branching-Strategie, wie Tests geschrieben und ausgeführt werden usw. All das spart dir viele Input tokens (Claude muss weniger „raten“, was es tun soll, indem es deine Codebase analysiert) und Output tokens (weil es durch das CLAUDE.md geführt wird, gibt es weniger Hin und Her).

Achtung allerdings: jedes Token in deinem CLAUDE.md wird beim Start jeder Session injiziert und neu gelesen. Ein CLAUDE.md von 5.000 Tokens sind 5.000 Input tokens, verbraucht, noch bevor du einen Prompt geschrieben hast. UND das multipliziert sich mit der Anzahl der Sessions an deinem Tag. Es muss kurz und präzise bleiben: mach daraus keine vollständige Dokumentation deines Projekts.

Die Größe deiner Sessions steuern

Claude schickt bei jeder Runde systematisch den vorherigen Kontext zurück. Zwei Befehle erlauben, das zu steuern, mit sehr unterschiedlichem Verhalten:

• /compact :  komprimiert die Historie zu einer Zusammenfassung. Der Session-Faden bleibt erhalten, Claude weiß, was gemacht wurde. Nutzen, wenn du am selben Thema weiterarbeiten, aber etwas Platz freimachen willst. Du kannst eine Anweisung mitgeben, um die Zusammenfassung zu steuern: /compact retain the architecture decisions.
• /clear : setzt den Kontext auf null. Claude erinnert sich an nichts mehr. Nutzen, wenn du die Feature wechselst.

Einfache Regel: /compact zum Weitermachen, /clear zum Neustart.

Ein letzter Befehl: /cost. Er zeigt den Tokenverbrauch und die geschätzten Kosten der laufenden Session. Praktisch, um in Echtzeit zu sehen, was eine etwas zu gesprächige Session dich gekostet hat.

Claude führen

Claude Code liest deine Codebase nicht bei jeder Anfrage komplett. Es nutzt Suchtools, um die Dateien zu finden, die es braucht. Genau diese Tool-Aufrufe verbrauchen Tokens: eine Datei lokalisieren, ihren Inhalt lesen, eine andere suchen... Auf einer großen Codebase kann diese Exploration mehrere tausend Tokens ausmachen, manchmal nur um eine Datei zu finden.

Mit @path/to/file überspringst du diese Exploration: Claude bekommt die Dateien direkt, ohne sie suchen zu müssen. Bei einem Feature oder einem Bugfix identifiziere im Voraus die zu ändernden Dateien und die, die als Referenz dienen.

.claudeignore: ausschließen, was unnötig ist

Wie bei einer .gitignore kannst du eine Datei .claudeignore im Root deines Projekts anlegen, um Dateien und Ordner auszuschließen. Die Syntax ist identisch. Es ist zum Beispiel empfehlenswert, node_modules in Front-Projekten auszuschließen, .nuxt, oder vendor und var in Symfony-Projekten.

node_modules/
/var
.nuxt

Plane deine Entwicklungen

Sehr nützlich für große Features: die Planung. Lass Claude den Code analysieren, bevor du entwickelst, plane die Entwicklungsschritte, lass keinen Platz für Zweifel. Das Ziel ist, den Weg zur Feature klar zu detaillieren, was unbedingt gemacht werden muss, was nicht gemacht werden darf, die wichtigen Dateien zum Lesen usw. Ein Plan zerlegt sich oft so:

• Discovery-Phase
  • Die wichtigen Dateien, die Claude kennen muss
  • Die Anti-Patterns
  • Die externen APIs, die zu nutzen sind
• Phasen 1 bis X
  • Aufteilung der Entwicklung in Phasen (Phase 1 Back, 2 Front, 3 Tests) mit den Details zur Implementierung für jede Phase

Und das trifft sich gut, Claude Code hat ein natives Tool dafür: den plan mode, aktiviert mit dem Befehl /plan (oder zweimal Shift+Tab). Das ist ein Nur-Lese-Modus, in dem Claude deine Dateien lesen, deine Codebase analysieren, Fragen stellen kann, aber es kann weder eine Datei ändern noch einen Befehl ausführen. Es erzeugt einen Plan, den du gegliest, verfeinerst, dann validierst. Erst nach deiner Validierung verlässt es den Plan mode und führt aus.

Auch wenn es kontraintuitiv wirken kann, einen großen Plan zu erzeugen: die Tokenersparnis ist real. Eine misslungene Implementierung kostet die Tokens der initialen Exploration, die der falschen Implementierung, die zum Erkennen des Fehlers und die zum Korrigieren. Der Plan mode erlaubt, all das vorwegzunehmen.

Die Modelle mischen

Es ist verlockend, das beste Modell alles machen zu lassen. Man stellt Opus ein und macht alles damit. Aber das ist in 90% der Fälle unnötig und vor allem verbraucht es enorm.

Eine Logik, die man übernehmen kann: Opus zum Planen, Sonnet zum Ausführen. Man lässt das fortschrittlichste Modell die Aufgabe planen, und Sonnet reicht völlig, um den Plan auszuführen.

Der Preisunterschied ist signifikant: Sonnet 4.6 ist 40% günstiger pro Input-Token und 40% günstiger pro Output-Token als Opus. Und da die Mehrheit der Tokens einer Entwicklungssession während der Ausführung verbraucht wird, ist der Gewinn gegenüber einer kompletten Session auf Opus erheblich.

Claude Code integriert dieses Pattern nativ mit dem Befehl /model und der Option opus-plan:

/model opus-plan

Wenn du diese Option aktivierst, routet Claude Code Planungsaufgaben automatisch zu Opus und Ausführungsaufgaben zu Sonnet in derselben Session. Du musst das Modell nicht manuell wechseln und auch keine zwei getrennten Kontexte verwalten.

In der Praxis sieht das so aus:

1. Du beschreibst dein Feature → Opus analysiert, denkt nach, erzeugt den Plan
2. Du validierst den Plan → Sonnet übernimmt die Implementierung

Ein Plan kostet ein paar hundert Tokens. Ein falscher Diff von 400 Zeilen, den du rückgängig machst und neu erzeugst, kostet Tausende, zweimal, plus die Runden, um zu erklären, was nicht stimmte.

Hör auf zu plaudern

Das ist nicht der verrückteste Trick, um Tokens zu sparen, aber hör auf, mit Claude Code zu reden, als wäre es dein Kollege! Sei weniger wortreich in deinen Prompts, ich sehe immer noch viele Kollegen, die ihren Prompt schreiben, wie man ein Bug-Ticket formuliert.

Da sitzt eine KI gegenüber, man muss nicht so wortreich sein. Man kann direkter sein.

Der Unterschied ist ziemlich groß. Hier ist es für das Beispiel etwas übertrieben und es ist ein kleiner Prompt, aber stell dir bei einem großen Plan vor, wie viele Tokens verloren gehen...

Ein paar praktische Tools

Claude-mem, ein Gedächtnis für Claude

Wir haben oben gesagt, dass eine Context window zwischen zwei Sessions auf null zurückgeht und dass nur das CLAUDE.md bestehen bleibt. Das stimmt standardmäßig. Aber es gibt ein Plugin, das das ändert: claude-mem.

claude-mem ist ein Claude-Code-Plugin, das automatisch erfasst, was Claude während deiner Code-Sessions macht, diese Beobachtungen komprimiert und sie als Kontext in die folgenden Sessions wieder injiziert. Alles lokal in einer SQLite-Datenbank gespeichert.

Kurz gesagt: du arbeitest zwei Stunden an einem Authentifizierungs-Bug, du schließt Claude Code, du kommst am nächsten Tag zurück. Die nächste Session startet schon wissend, woran du gearbeitet hast. Der Bug, den du am Vortag behoben hattest? Claude erinnert sich. Es wird die schon analysierten Dateien nicht nochmal lesen und auch nicht auf dieselben schlechten Hypothesen zurückfallen, die du schon ausgeschlossen hattest.

Was claude-mem gegenüber einer einfachen Injektion ins CLAUDE.md interessant macht, ist die Kompression: das rohe Transkript einer langen Session kann Zehntausende Tokens ausmachen. claude-mem destilliert es zu kurzen, typisierten Beobachtungen (Bugfix, Entscheidung, Entdeckung), sodass der Recall sehr wenig kostet.

Installation:

# Depuis une session Claude Code

/plugin marketplace add thedotmack/claude-mem

/plugin install claude-mem

Caveman, zurück in die Steinzeit

Wenn du Claude Code schon mal gebeten hast, eine kleine Funktion zu schreiben, und es mit drei Einleitungsabsätzen geantwortet hat, bevor es eine Zeile Code geschrieben hat — du siehst das Problem. Diese Tokens der Höflichkeit, der Kontextualisierung und der Umformulierung sind pure Verschwendung.

Das ist die Idee hinter caveman: ein Claude-Code-Skill, der den Agenten wie einen Höhlenmenschen sprechen lässt — entfernt das Füllmaterial, behält die Substanz, nutzt Fragmente. Das schneidet etwa 75% der Output tokens weg und behält die technische Genauigkeit bei.

Die Logik ist einfach: caveman betrifft nur die Output tokens — die Reasoning-Tokens bleiben unberührt. Caveman macht das Gehirn nicht kleiner. Es macht den Mund kleiner.

Es gibt mehrere Intensitätsstufen:

- lite : entfernt nur die Höflichkeitsformeln und das Füllmaterial

- full : wechselt in den Fragmentstil

- ultra : maximale Kompression, nützlich wenn jedes Token zählt, weniger lesbar zum Debuggen eines komplexen Fehlers. Ein echter Höhlenmensch, grrrr

Und als Bonus: Caveman Compress ist ein separates Feature, das dein CLAUDE.md in Caveman-Speak umschreibt, was die Input tokens statt der Output tokens reduziert. Funktioniert auch auf jeder anderen Datei, die du ihm gibst, zum Beispiel einem gespeicherten Plan.

Installation:

/plugin marketplace add JuliusBrussee/caveman

/plugin install caveman@caveman

Dann in einer Session:

/caveman        # mode par défaut

/caveman lite   # supprime juste le remplissage

/caveman full   # réponses en fragments

/caveman ultra  # compression maximale

Um ehrlich zu sein, das spart dir ein paar hundert Tokens, also ist es kein Gamechanger. Nein. Der echte Vorteil von caveman ist eher die Lesegeschwindigkeit und die Begrenzung des Rauschens.

Tokscale, deine Rentabilität visualisieren

Man kann nicht optimieren, was man nicht misst. /cost gibt dir die Kosten der laufenden Session, aber nichts über deine Trends über die Woche oder den Monat.

tokscale füllt diese Lücke. Es ist ein CLI-Tool mit einer interaktiven Oberfläche, das deinen Tokenverbrauch über alle deine Claude-Code-Sessions aggregiert und ihn aus mehreren Blickwinkeln zeigt:

- Overview : Gesamtverbrauch, geschätzte Kosten, Trend

- Daily / Hourly : die Tage oder Zeitfenster identifizieren, in denen du überverbrauchst

- Models : Verteilung nach Modell (nützlich, wenn du Sonnet und Opus mischst)

- Agents : Detail nach Session und nach Agent

Was praktisch ist: tokscale verbindet sich mit keinem externen Dienst, es liest direkt die lokalen Logs von Claude Code. Und wenn du andere Tools nutzt (Cursor, Gemini CLI, Codex...), aggregiert es alles an einem Ort.

Installation:

npm install -g tokscale

Dann:

tokscale               # vue interactive complète

tokscale --week        # consommation sur 7 jours

tokscale --client claude  # filtrer sur Claude Code uniquement

tokscale models        # détail par modèle

CodeBurn, der präzise Überblick deines Verbrauchs

Etwas vollständiger als tokscale. CodeBurn lässt dich präziser visualisieren, wohin deine Tokens gehen, bis auf Aufgabenebene.

Es liest die Session-Transkripte, die lokal in ~/.claude/projects/ gespeichert sind, und klassifiziert jeden Austausch in 13 Kategorien, basierend auf den Nutzungsmustern der Tools.

Die Kategorien: coding, debugging, exploration, brainstorming — und vor allem conversation, die Austausche, in denen Claude antwortet, ohne irgendein Tool zu nutzen. Da kommt die Überraschung: für den Ersteller des Tools, der 200$/Tag auf Claude Code ausgab ohne Sichtbarkeit, ging mehr als die Hälfte des Budgets in reine Konversation, nicht in Codegenerierung.

CodeBurn ist Open Source und läuft vollständig lokal. Es bietet ein interaktives TUI-Dashboard mit macOS-Menüleisten-Support über SwiftBar, CSV/JSON-Export und Breakdown nach Projekt, Modell, Tool und MCP-Server.

npx codeburn

RTK (Rust Token Killer)

RTK packt das Problem an einer Stelle an, die niemand adressiert hatte: die CLI-Outputs, die Claude in den Kontext injiziert.

Die Idee ist einfach: die meisten CLI-Outputs, die an das LLM geschickt werden, sind Rauschen: Tests, die durchlaufen, wortreiche Logs, Progressbars usw. RTK ist ein CLI-Proxy, der diese Outputs filtert und komprimiert, bevor sie die Context window erreichen.

Die vom Autor veröffentlichten Zahlen sind ziemlich beeindruckend: cargo test geht von 155 Zeilen auf 3 Zeilen (98% Reduktion), git status von 119 auf 28 Zeichen (76%). Bei intensiver Nutzung rechnet sich das sehr schnell.

RTK wird außerhalb von Claude installiert und klinkt sich in Claude ein, um die Anfragen abzufangen. Es unterstützt mehr als 100 Befehle: git, pytest, cargo, docker, kubectl, eslint, tsc…

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | sh
rtk init -g  # installe le hook Claude Code
rtk gain     # affiche les tokens économisés

Derselbe Init-Befehl funktioniert für Cursor, Codex, Windsurf, Gemini CLI — kohärent mit der Philosophie des Artikels: die Prinzipien gelten für alle LLM-basierten Tools.

Zum Schluss

Voilà, du weißt jetzt mehr über die Funktionsweise von Claude, darüber, was Tokens sind, wohin sie gehen, und wie man sie gut spart.

Klar, wenn du auf MAX-Plänen bist, ist der Tokenverbrauch wahrscheinlich nicht deine Priorität; und selbst dann, mit den neuen Modellen, beginnen selbst die MAX-Pläne ihre Grenzen zu zeigen. Aber auf niedrigeren Plänen hast du jetzt ein paar Tools, um mehr aus deinem Quota herauszuholen.

Schau dir gern die Quellen im Anhang an, um tiefer zu gehen, Claude Code ist deutlich komplexer, wenn man wirklich in die Details einsteigen will!