Token-Effizienz in Claude Code: Was wirklich hilft – und was Clickbait ist

Vorweg, weil es beim Thema sonst sofort rutschig wird: Ich nutze Claude Code im Max 5x Plan, primär für Python, Handlebars, PHP und TypeScript, gelegentlich Audits und gröberes Refactoring. Selbst bei langen Iterationen stoße ich erstaunlich selten ans Limit – und genau dieser Eindruck war der Anlass, mal genauer hinzuschauen, was hinter dem Token-Verbrauch in Claude Code eigentlich steckt. Außerdem geistert ein Medium-Artikel durchs Netz, der verspricht, mit ein paar Tricks 90 % der Tokens zu sparen. Reality-Check inklusive.

Wie Token in Claude Code wirklich verbraucht werden

Bevor irgendein Spar-Tipp Sinn ergibt, muss man verstanden haben, wo die Tokens eigentlich hingehen. Kurz und schmerzlos:

Bei jedem Turn schickt Claude Code den gesamten Conversation-Verlauf mit – Prompts, Antworten, jede gelesene Datei, jeder Tool-Output, dazu die CLAUDE.md und alles, was sonst noch im Context-Window liegt. Das ist keine Anthropic-Eigenheit, sondern wie Transformer-Modelle funktionieren: Sie haben kein Gedächtnis, sie haben einen Context. Anthropic schreibt in der offiziellen Doku selbst, dass eine einzige Debug-Session zehntausende Tokens verbrauchen kann – und dass die Performance schlechter wird, je voller das Context-Window läuft. Das nennt sich „context rot“ und ist auch in der API-Doku dokumentiert.

Eine vielzitierte Zahl im deutschsprachigen Raum kommt von Sascha Hoffmann: 98,5 % der Tokens gehen ins Lesen, nur 1,5 % in den eigentlichen Output. Die Zahl bezieht sich zwar auf Claude im Web/App, nicht auf Claude Code – aber sie ist mit zwei Einordnungen interessant. Erstens: In Claude Code ist das Verhältnis tendenziell noch schiefer, weil Datei-Reads, Bash-Outputs, MCP-Responses und Tool-Calls den Input zusätzlich aufblähen. Web-Chat hat im Wesentlichen Conversation-History als Reading-Anteil, Claude Code hat das plus alle I/O-Operationen. Zweitens, und das ist die wichtige Differenzierung: Das ist eine Volumen-Verteilung und keine Kostenverteilung. Output-Tokens sind pro Token rund 5× teurer als Input-Tokens (bei Sonnet 4.6 sind das $3/Mio. Input vs. $15/Mio. Output, bei Opus 4.7 entsprechend $5 vs. $25 – das 1:5-Verhältnis zieht sich durch die gesamte Claude-Familie).

Aber für die Subscription-Pläne ist das auch egal, weil dort eben alle Tokens gegen denselben Pool laufen, unabhängig vom Pro-Token-Preis. Auf Pro/Max-Plänen drückt also tatsächlich der riesige Reading-Anteil das Limit – die Aussage stimmt für Subscription-Nutzer in ihrer praktischen Konsequenz, auch wenn sie auf API-Ebene differenzierter wäre.

Daraus folgen zwei Dinge: Erstens ist die Token-Zahl pro Turn nicht das, was Du gerade in den Prompt getippt hast – sondern alles, was sich seit Session-Start angesammelt hat. Zweitens ist „Tokens sparen“ in Claude Code kein Buchhaltungsthema, sondern eines der Output-Qualität. Ein verschmutzter Context produziert schlechteren Code.

Die belastbaren Hebel

Anthropic hat eine eigene Best-Practices-Seite und eine Costs-Seite – beides naturgemäß mit Anbieter-Bias zu lesen, aber überraschend ehrlich, was die Schwächen des Tools angeht. Das, was sich quer durch unabhängige Quellen (KDnuggets, DEV Community, buildtolaunch) als belastbar herauskristallisiert, sind im Wesentlichen sechs Dinge:

/clear zwischen unzusammenhängenden Tasks. Der einfachste, wirksamste Hebel. Sobald Du das Thema wechselst, hat alles Vorherige im Context nichts mehr zu suchen – es kostet Tokens und verschlechtert die Antworten. Anthropic empfiehlt das in der Doku explizit, und das ist einer der wenigen Tipps, der wirklich für jeden gilt.

CLAUDE.md schlank halten. Diese Datei wird bei jedem Turn mitgeschickt – jede Zeile darin ist also ein Dauer-Abo. KDnuggets bringt es auf den Punkt: eine 5.000-Token-CLAUDE.md kostet 5.000 Tokens pro Turn, egal ob Du zwei oder zweihundert Nachrichten sendest. Anthropic empfiehlt selbst eine Faustformel für jede Zeile: „Würde ohne diese Zeile Claude Fehler machen?“ Wenn nein, raus damit. Realistische Größenordnung laut Praktikern: 300–600 Tokens, alles über 2.000 ist meistens schon Bloat.

.claudeignore einrichten. Wirkt wie .gitignore und hält Claude davon ab, Lock-Files, node_modules, Build-Artefakte und generierten Code zu indizieren. Klingt banal, aber wer schon mal beobachtet hat, wie Claude eine 5.000-Zeilen-Lockfile einliest, weiß, wo das hinführt.

Plan Mode für nicht-triviale Änderungen. Shift+Tab aktiviert ihn, Claude erstellt erst einen Plan, bevor Code fließt. Verhindert das teuerste Pattern überhaupt: Trial-and-Error-Iterationen, bei denen Claude Sachen ausprobiert, scheitert, korrigiert, wieder scheitert – und bei jeder Runde der gesamte Context erneut durch die Mühle muss.

Modellwahl bewusst. Nicht für jede Aufgabe braucht es Opus. Sonnet ist für Alltagskram (Tests schreiben, Refactoring, Erklären) qualitativ ausreichend und in der API-Welt deutlich günstiger als Opus (Sonnet 4.6 $3/$15 vs. Opus 4.7 $5/$25 pro Mio. Tokens). Auf Subscription-Plänen drainen Opus-Tasks den Pool entsprechend schneller. Es gibt mit opusplan sogar einen Hybrid-Modus, der für die Planung Opus nutzt und für die Implementierung auf Sonnet zurückfällt. Sascha Hoffmann empfiehlt im selben Sinn, Haiku für triviale Tasks zu verwenden – Lookups, Renames, Formatieren. Das ist auf Subscription-Plänen bemerkbar, auf der API-Seite ohnehin günstiger.

Subagents für I/O-lastige Recherche. Dazu gleich mehr.

Das sind die Hebel mit nachvollziehbaren Mechanismus. Alles andere, was Du im Netz findest, ist meistens entweder eine Variante davon oder Wunschdenken.

Der Medium-Artikel und sein 90-%-Versprechen

Der oft verlinkte Medium-Artikel von Mehul Gupta verspricht im Titel 90 % Token-Ersparnis. Drei Minuten Lesezeit, sieben Tipps, keine einzige Quelle, keine Messung, kein Benchmark. Die 90 % stehen einfach so im Titel und kommen im Text nie wieder vor.

Was drin steht, ist eine Mischung aus Banalem und teilweise sogar Falschem. „Sessions kurz halten“, „/clear benutzen“, „nicht zu viel Kontext pasten“ – ja, klar, das steht so auch in der Anthropic-Doku, nur ohne Knall-Headline. Keine Hilfe, aber auch nicht schädlich.

Problematischer ist Tipp 3: „Batch tasks instead of splitting them“ – also alles in einen Riesen-Prompt packen statt in mehrere Schritte. Das widerspricht ziemlich direkt dem, was Anthropic selbst empfiehlt und was die unabhängigen Quellen zeigen: kleine, fokussierte Sessions schlagen die Marathon-Variante in Qualität und Kosten. Ein Batch-Prompt verhindert nicht, dass der Context bei der Ausführung explodiert – er verschiebt das Problem nur an den Anfang. Und Plan Mode wird dadurch faktisch unmöglich.

Tipp 7 („Keep prompts simple and direct“) ist sogar kontraproduktiv. Anthropic empfiehlt das Gegenteil: spezifischen Kontext liefern, konkrete Dateien referenzieren (@-Syntax), Verifikationskriterien mitgeben. Vage Prompts führen genau zu dem teuren Suchverhalten, das man eigentlich vermeiden will – Claude liest dann zehn Dateien, weil es nicht weiß, in welcher das Problem sitzt.

Kurz: Der Artikel ist ein Listicle, das Bekanntes ohne Substanz aufwärmt und an einer Stelle aktiv schlechte Empfehlungen gibt. Die 90 % im Titel sind aus der Luft gegriffen. Wer wissen will, was wirklich hilft, ist mit der Anthropic-Doku selbst, KDnuggets oder dem DEV-Artikel deutlich besser bedient.

Subagents und Orchestrierung – kurz und ehrlich

Subagents sind der Mechanismus, mit dem Claude Code Recherche und I/O aus dem Haupt-Context heraushält. Vereinfacht: Du sagst „erforsche, wie wir Token-Refresh machen“, Claude startet einen Subagent in eigenem Context-Window, der liest dort zwanzig Dateien, und am Ende kommt eine Zusammenfassung in Deinen Haupt-Thread zurück – nicht die zwanzig Dateien selbst. Der Anthropic-Doku-Eintrag dazu erklärt das gut.

Klingt nach einem Free Lunch, ist es aber nicht. Anthropic dokumentiert in der Costs-Seite selbst, dass Agent Teams (also mehrere Subagents in Plan Mode) rund 7× mehr Tokens verbrauchen als eine normale Session, weil jeder Teammate sein eigenes Context-Window mit CLAUDE.md, MCP-Servern und Skills lädt. Ein DEV-Bericht beschreibt einen Refactoring-Lauf, in dem fünf parallele Subagents den Pro-Plan in 15 Minuten leergesaugt haben – sequenziell hätte derselbe Job 30 Minuten gedauert und deutlich weniger Tokens gekostet. Der Witz an Parallelismus ist nicht „weniger Tokens“, sondern „weniger Wallclock-Zeit bei mehr Tokens“.

Praktische Daumenregel: Subagents sparen, wenn der vermiedene Müll im Haupt-Context größer ist als der Overhead durch Setup, Tool-Definitionen und Round-Trips. Bei Recherche über viele Dateien lohnt sich das fast immer. Bei kleinen Shell-Aktionen oder kurzen Git-Operationen ist es Verschwendung.

Für meinen Workload – einzelne Module in Python, Handlebars, TypeScript, PHP – benötigte ich Subagents selten und Agent Teams eigentlich nie. Das deckt sich mit dem, was Praktiker im Netz beschreiben: Multi-Agent-Setups sind primär für große Refactorings über hunderte Dateien oder echte Parallelarbeit relevant. Für „normale“ Entwicklung sind sie eher mit Kanonen auf Spatzen geschossen.

Der Max-Plan und mein Eindruck mit der „anderen Staffelung“

Mein Bauchgefühl beim Schreiben war: Im Max-Plan scheint der Token-Verbrauch anders gestaffelt zu sein als in den günstigeren Tarifen. Die Recherche zeigt: Das stimmt so nicht, beziehungsweise – es ist nicht ganz das, was ich gemeint habe.

Anthropic veröffentlicht keine harten Token-Caps für die Subscription-Pläne. Was es gibt, sind die Multiplikatoren 5× und 20× gegenüber Pro, Reset alle fünf Stunden plus Wochen-Caps. Pro Token wird in Max nichts billiger – derselbe Prompt mit denselben Files verbraucht in Pro, Max 5x und Max 20x identisch viele Tokens. Was anders ist: der Pool, gegen den diese Tokens laufen, ist deutlich größer. Unabhängige Auswertungen sprechen von grob ~225 kurzen Nachrichten pro 5-Stunden-Fenster bei Max 5x gegenüber ~40–45 bei Pro – aber das sind grobe Schätzungen, keine offiziellen Zahlen.

Mein Eindruck der „anderen Staffelung“ ist also vermutlich genau das: Der Pool ist groß genug, dass mein Nutzungsprofil – einzelne Anwendungen, mittellange Sessions, gelegentliches Refactoring – schlicht nicht in die Limits läuft. Das ist kein Tarif-Vorteil pro Token, das ist Pool-Größe. Wer in Max-20x-Bereiche kommt, hat entweder Agent-Team-Workflows oder dauerhaft Multi-Session-Setups laufen – beides Größenordnungen, die bisher bei mir schlicht nicht vorkamen.

Was am Ende übrig bleibt

Der ehrliche Stand ist erstaunlich unspektakulär: Die wirksamen Hebel zur Token-Effizienz sind kein Geheimwissen. /clear, schlanke CLAUDE.md, .claudeignore, Plan Mode, bewusste Modellwahl, Subagents nur dort wo sie passen. Das steht so in der Anthropic-Doku, das findet sich in jedem ernsthaften unabhängigen Artikel, und es funktioniert.

Die „90 % sparen mit diesen sieben Tricks“-Beiträge sind meistens Listicles, deren Tipps entweder banal, ungenau gemessen oder im schlechtesten Fall sogar kontraproduktiv sind. Wer seine Sessions ehrlich verfolgen will, fährt mit /usage und /cost in Claude Code besser als mit irgendeinem Artikel-Schnellrezept.

Und die Max-Frage: Pro Token ist nichts günstiger. Der Pool ist größer. Ob das den Aufpreis wert ist, hängt schlicht davon ab, wie oft Du heute in Pro-Limits läufst – nicht davon, ob Tokens irgendwie „anders gerechnet“ werden.