{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihd2sczphq6qe4lckxzi5ymdwt7lfo3kpdunyfhtfzxptp2ax3lwa",
    "uri": "at://did:plc:jcdhsk6w7rxuehjvjgwrwr7d/app.bsky.feed.post/3mmvcpxtpxck2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreid7zgxno3ns5qzgmb7nqjtlygt74c6pyim4vk42bb67usojk6yf2q"
    },
    "mimeType": "image/webp",
    "size": 65772
  },
  "description": "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 s",
  "path": "/ai-dev/token-effizienz-in-claude-code-was-hilft/",
  "publishedAt": "2026-05-28T05:40:46.000Z",
  "site": "https://t01.li",
  "tags": [
    "eine einzige Debug-Session zehntausende Tokens verbrauchen kann",
    "auch in der API-Doku dokumentiert",
    "Sascha Hoffmann",
    "Best-Practices-Seite",
    "Costs-Seite",
    "KDnuggets",
    "DEV Community",
    "buildtolaunch",
    "eine 5.000-Token-CLAUDE.md kostet 5.000 Tokens pro Turn, egal ob Du zwei oder zweihundert Nachrichten sendest",
    "Hybrid-Modus, der für die Planung Opus nutzt und für die Implementierung auf Sonnet zurückfällt",
    "Medium-Artikel von Mehul Gupta",
    "Anthropic selbst empfiehlt",
    "DEV-Artikel",
    "Anthropic-Doku-Eintrag dazu",
    "DEV-Bericht",
    "veröffentlicht keine harten Token-Caps",
    "Unabhängige Auswertungen",
    "@-Syntax"
  ],
  "textContent": "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.\n\n##  TL;DR\n\n„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.\n\nDie 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.\n\nWas 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.\n\nUnd der Max-Plan, der angeblich anders rechnet? Tut er nicht. Pro Token wird nichts billiger – der Pool ist nur größer.\n\n## Wie Token in Claude Code wirklich verbraucht werden\n\nBevor irgendein Spar-Tipp Sinn ergibt, muss man verstanden haben, wo die Tokens eigentlich hingehen. Kurz und schmerzlos:\n\nBei 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.\n\nEine 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).\n\nAber 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.\n\nDaraus 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.\n\n## Die belastbaren Hebel\n\nAnthropic 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:\n\n**`/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.\n\n**`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.\n\n**`.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.\n\n**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.\n\n**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.\n\n**Subagents für I/O-lastige Recherche.** Dazu gleich mehr.\n\nDas sind die Hebel mit nachvollziehbaren Mechanismus. Alles andere, was Du im Netz findest, ist meistens entweder eine Variante davon oder Wunschdenken.\n\n### Der Medium-Artikel und sein 90-%-Versprechen\n\nDer 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.\n\nWas 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.\n\nProblematischer 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.\n\nTipp 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.\n\nKurz: 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.\n\n### Subagents und Orchestrierung – kurz und ehrlich\n\nSubagents 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.\n\nKlingt 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“.\n\nPraktische 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.\n\nFü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.\n\n### Der Max-Plan und mein Eindruck mit der „anderen Staffelung“\n\nMein 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.\n\nAnthropic 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.\n\nMein 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.\n\n### Was am Ende übrig bleibt\n\nDer 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.\n\nDie „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.\n\nUnd 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.",
  "title": "Token-Effizienz in Claude Code: Was wirklich hilft – und was Clickbait ist",
  "updatedAt": "2026-05-29T19:22:05.333Z"
}