> ## Content Index > Fetch the complete content index at: https://t01.li/llms.txt > Use this file to discover other available public pages before exploring further. # Token-Effizienz in Claude Code: Was wirklich hilft – und was Clickbait ist - URL: https://t01.li/ai-dev/token-effizienz-in-claude-code-was-hilft/ - Published: 2026-05-28T05:40:46.000Z - Updated: 2026-07-16T15:04:26.000Z - Author: Tobias Glawe - Tags: AI Dev 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. ## TL;DR „Tokens sparen“ in Claude Code klingt nach Buchhaltung, ist aber ein Qualitätsthema. Bei jedem Turn wandert der gesamte Verlauf mit – Prompts, Antworten, jeder Datei-Read, jeder Tool-Output, die `CLAUDE.md`. Je voller der Context, desto schlechter der Code. Context Rot, nicht Geiz, ist das eigentliche Problem. Die wirksamen Hebel sind kein Geheimwissen, sie stehen so in der Anthropic-Doku: `/clear` zwischen unzusammenhängenden Tasks, eine schlanke `CLAUDE.md` (300 bis 600 Tokens, nicht 5.000), eine `.claudeignore` gegen Lock-Files und node\_modules, Plan Mode für nicht-triviale Änderungen und bewusste Modellwahl – Sonnet oder Haiku statt reflexhaft Opus. Was nicht hilft, ist der kursierende Medium-Artikel mit dem „90 % sparen“-Versprechen. Die Zahl steht im Titel und taucht im Text nie wieder auf, zwei der sieben Tipps – alles in einen Riesen-Prompt batchen, Prompts simpel halten – sind sogar kontraproduktiv. Auch Subagents sind kein Free Lunch: Agent Teams verbrauchen laut Anthropic rund siebenmal mehr Tokens, der Gewinn ist weniger Wartezeit, nicht weniger Verbrauch. Und der Max-Plan, der angeblich anders rechnet? Tut er nicht. Pro Token wird nichts billiger – der Pool ist nur größer. ## 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 [Kontextfenster](https://t01.li/glossar/#kontextfenster) 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](https://code.claude.com/docs/en/best-practices?ref=t01.li) – 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](https://platform.claude.com/docs/en/build-with-claude/context-windows?ref=t01.li). Eine vielzitierte Zahl im deutschsprachigen Raum kommt von [Sascha Hoffmann](https://www.youtube.com/watch?v=hdnAl4kUUdM&ref=t01.li): 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](https://t01.li/glossar/#tool-calling) 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](https://code.claude.com/docs/en/best-practices?ref=t01.li) und eine [Costs-Seite](https://code.claude.com/docs/en/costs?ref=t01.li) – 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](https://www.kdnuggets.com/7-practical-ways-to-reduce-claude-code-token-usage?ref=t01.li), [DEV Community](https://dev.to/boucle2026/7-ways-to-cut-your-claude-code-token-usage-elb?ref=t01.li), [buildtolaunch](https://buildtolaunch.substack.com/p/claude-code-token-optimization)) 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](https://www.kdnuggets.com/7-practical-ways-to-reduce-claude-code-token-usage?ref=t01.li). 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](https://claudefa.st/blog/guide/development/usage-optimization?ref=t01.li). 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](https://medium.com/data-science-in-your-pocket/reduce-claude-code-token-usage-by-90-baa2a27b9ca3?ref=t01.li) 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](https://code.claude.com/docs/en/best-practices?ref=t01.li) 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](https://www.kdnuggets.com/7-practical-ways-to-reduce-claude-code-token-usage?ref=t01.li) oder dem [DEV-Artikel](https://dev.to/boucle2026/7-ways-to-cut-your-claude-code-token-usage-elb?ref=t01.li) 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](https://code.claude.com/docs/en/sub-agents?ref=t01.li) erklärt das gut. Klingt nach einem Free Lunch, ist es aber nicht. Anthropic dokumentiert in der [Costs-Seite](https://code.claude.com/docs/en/costs?ref=t01.li) 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](https://dev.to/onlineeric/claude-code-sub-agents-burn-out-your-tokens-4cd8?ref=t01.li) 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](https://checkthat.ai/brands/anthropic/pricing?ref=t01.li) 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](https://intuitionlabs.ai/articles/claude-max-plan-pricing-usage-limits?ref=t01.li) 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.