94% meiner Claude Code Tokens gingen an das falsche Modell. Also hörte ich auf, Opus für Haikus Job zu bezahlen.

11 min read

Du denkst, du hast bei Claude Code alles richtig gemacht. Hooks installiert. CLAUDE.md auf 6.890 Token kuratiert. Jeden MCP-Server abgeschossen, mit der Art von Disziplin, auf die du am Freitagabend still und heimlich stolz bist.

Dann ist Mittwoch, drei Tage bevor deine wöchentlichen Limits zurückgesetzt werden, und du bist bereits bei 80% Verbrauch. Sogar im Max-Plan.

Da fragst du dich, was diese Disziplin eigentlich gebracht hat.

TLDR. Du kannst dein Claude Code Setup verbiegen wie du willst. Ich habe ein kostenloses Tool gefunden, das nicht über den Ballast lügt, Kosten drastisch senkt und Claude schärfer macht, nicht nur billiger. Hier ist, was ich getan habe und wie du es nachbauen kannst.

Monatelang hatte ich Boris Cherny zugehört und die Anthropic-Essays über Context Engineering gelesen. Ich hatte die Hausaufgaben gemacht. MCPs weg. CLAUDE.md gestutzt. Als ich auch die MEMORY-Dateien archiviert und den SessionEnd-Hook installiert hatte, sprachen die Zahlen für sich: 643 Sessions in dreißig Tagen mit null Abstürzen und null /context-Panik.

Am Ende meiner Token ging ich auf die Suche. Und fand einen Schatz. Ein Audit-Tool, das nicht nur Token zählt. Es sagt dir wann Claude dumm wird.

Geteilte Büro-Szene: gestresster Mitarbeiter umgeben von hohen Rechnungen und Ladescreens vs. entspannter Angestellter mit minimalen Kosten im Dashboard
Opus für Haikus Job bezahlen? Das ist nur teures Leiden.

Die Bewertung, die mich den Tab schließen ließ

Ich ließ es letzte Woche laufen. Sechs Agenten parallel, sechzig Sekunden. Erstes auf dem Bildschirm: Health Score C, 69 von 100.

Nicht D, nicht F. C. Die Note eines Kindes, das dachte, es hätte gut gelernt. Ich hatte Spielraum, oder was sage ich, einen Abgrund.

Total Session Overhead: 23,5K Token, 2,3% des Million-Token-Fensters. CLAUDE.md global bei 6.890. Skills bei 1.809. Commands 1K, null MCP-Tools, der Rest saß wo ich ihn erwartet hatte. Die Zahlen waren klein.

Und dann sah ich die Zeile, die mich aufhören ließ zu scrollen.

Real session baseline averages 43.2K tokens (+83.9% vs estimate). Gap is from unmeasured system overhead.

Das Audit-Tool sagte mir selbst, dass es untermessen hatte. Das XML-Framing, die MCP-Anweisungen, die System-Prompts, die mit jedem Model-Call mitgeliefert werden (gib zu, du checkst die auch nicht). Dinge, die ich nie in /context sehe, für die ich aber bei jeder einzelnen Nachricht bezahlt hatte.

Was ich zu messen glaubte, war die Hälfte dessen, was tatsächlich abgerechnet wurde.

Das war der Moment, in dem das Framing kippte. Die Bewertung ist eine Architektur-Note, verkleidet als Füllstandsanzeige. Die Hälfte des Ballasts, für den ich bezahlte, sah ich nie.

Token-Schulden sind nicht nur finanziell

Jeder Medium-Post über Claude Code-Kosten rahmt es gleich. Dein Kontext ist voll. Du zahlst zu viel. Stutze deine CLAUDE.md.

Halb richtig. Die andere Hälfte ist, dass Token-Schulden dual sind.

Die finanzielle Ebene ist die offensichtliche. Die Anthropic API ist stateless. Jeder Turn lädt den gesamten Stack neu. Prompt Caching teilt die Kosten durch zehn, aber das Fenster selbst schrumpft nicht. Wenn du also eine Geisterdatei von 1.410 Token in MEMORY für ein abgeschlossenes Projekt liegen hast, und du sendest 3.347 Nachrichten am Tag, und das machst du achtzehn Tage lang... das sind 85 Millionen Token für null Wert abgerechnet. Von einer Datei.

Zur Einordnung: 137 Millionen abrechenbare Token habe ich letzten Monat insgesamt durchgejagt. Eine Geisterdatei allein fraß mehrere Prozent des Volumens. In Stille.

Die kognitive Ebene ist die, über die niemand spricht. Laut Anthropics veröffentlichter Anleitung und bestätigt durch das Design des Audit-Tools sinkt die Qualität nach 50-70% Kontext-Füllung. Compaction ist verlustbehaftet. Mit 9,7 Millionen Token durchschnittlich pro Session in einem Eine-Million-Token-Fenster sind das etwa zehn Compactions pro Session. Sechstausend Compactions in dreißig Tagen. Jede schält etwas ab (eine Regel, eine Konvention, ein Scope-Stück, das du vor zwei Stunden gesetzt hattest).

Und dann ist da der Overhead, den du nicht sehen kannst. Anthropics eigenes Engineering-Team berichtete, dass MCP-Tool-Definitionen 134K Token verbrauchten, bevor sie Tool Search auslieferten. Ein Reddit-User dokumentierte 67.000 Token weg, nur vom Verbinden von vier MCP-Servern. Nichts davon taucht in /context auf.

Ungenutzte Token kosten dich Geld. Die größeren Kosten entstehen dadurch, dass du dafür bezahlst, die Qualität deines eigenen Denkens zu verschlechtern, bei jedem Turn.

Ich hatte im Februar geschrieben, dass CLAUDE.md die neue .env ist, nicht die neue README. Ich behandelte die Datei als Config-Problem. Das war die halbe Wahrheit. Die kognitive Ebene hatte ich nicht gesehen.

Sechs Agenten, sechzig Sekunden, ein Urteil

Das Tool heißt token-optimizer. Es ist ein Claude Code Plugin, Open Source, auf Alex Greenshs GitHub. Du installierst es mit einer Zeile: /plugin marketplace add alexgreensh/token-optimizer.

Die Architektur ist ehrlich. Sechs Agenten laufen parallel. Sonnet übernimmt die Bewertungsaufgaben, Haiku macht die Zählarbeit, und Opus kommt nur am Ende für die Synthese dazu. Ein Dashboard lebt auf localhost:24842 und aktualisiert sich automatisch bei jedem SessionEnd-Hook.

Was es macht, was nichts anderes macht: es verfolgt wie viel dümmer deine KI wird, während die Session voranschreitet. Zitat aus dem Repo, nicht von mir. /context zeigt dir die Anzeige. Das hier zeigt dir die Architektur unter der Anzeige UND den Qualitätsverlust über die Zeit.

Das Tool gibt auch seine eigenen Grenzen zu. Die +83,9% Untermessung, die ich früher zitiert habe? Sie kommt daher, dass das Audit mir selbst sagt: "Gap is from unmeasured system overhead." Ein Tool, das zu dem steht, was es nicht sehen kann, ist glaubwürdiger als eines, das vorgibt, alles zu sehen.

Vor drei Wochen schrieb ich über den Tag, an dem mein Pro Max Plan fünfzehn Minuten hielt, bevor ich /context laufen ließ und den Ballast zum ersten Mal sah. Ich dachte, ich hätte das Schlimmste gesehen. /context sagt dir, der Kühlschrank ist voll. Token-optimizer sagt dir, die Hälfte des Essens ist abgelaufen.

Es passt auch zu einer These, die ich seit Monaten vorantreibe. Der Grund, warum das funktioniert, ist, dass es ein CLI-natives Plugin ist, kein MCP-Server. Es läuft innerhalb von Claude Codes Ausführungsschleife, nicht über ein Remote-Tool-Protokoll. Es ist ein kleiner Datenpunkt dafür, warum CLI-native Tools MCP-Server für KI-Agenten schlagen.

Sechs Agenten, sechzig Sekunden, ein Dashboard. Und jeden Befund, den es produziert, musst du selbst anwenden.

Der sichtbare Hebel zahlt sich am wenigsten aus

Hier ist, was das Audit zuerst fand. Drei Projekt-MEMORY-Dateien, archiviert von abgeschlossener Arbeit. Eine davon war allein 1.410 Token. Rechne nach: 1.410 Token × 3.347 Nachrichten am Tag × 18 Tage, die die Datei in MEMORY saß, nachdem ich aufgehört hatte, das Projekt anzufassen. Das sind 85 Millionen Token für null Wert abgerechnet, von einer Datei.

Zur Einordnung, mein gesamter abrechenbarer Verbrauch in dem Monat waren 137 Millionen. Eine Geisterdatei fraß etwa 0,6% meines gesamten monatlichen Volumens, während sie nichts beitrug.

Multipliziere das über die anderen: zwei weitere archivierte MEMORY-Dateien. Sechs Zitate alter Twitter-Vorfälle in der globalen CLAUDE.md, pensioniert. Wortreiche Skill-Beschreibungen gestutzt. Plugin-Commands, die ich nie aufgerufen hatte, beschnitten.

Das gesamte gemessene Cleanup: -1.386 Token pro Nachricht auf der Datei-Ebene, ein Rückgang von 5,9%. Plus weitere 2.565 Token vom On-Demand-Korpus geschält.

Die Regel, die ich verallgemeinern würde: wenn eine MEMORY-Datei 14 Tage lang nicht in einem Prompt referenziert wurde, archiviere sie standardmäßig. Anthropics Docs empfehlen eine 200-Zeilen Auto-Load-Obergrenze. Die echte praktische Obergrenze sind 14 Tage Referenz.

Jetzt kommt die unbequeme Wahrheit.

5,9% ist nicht der halbe Bissen Brot, nach dem es klingt. Es ist die Schicht, die du sehen kannst, was sie zur Schicht macht, auf die sich alle versteifen. Aber es ist auch die Schicht, die sich am wenigsten auszahlt.

Die Geisterdatei ist die Vorspeise. Der Hauptgang ist woanders.

Zwei Best Practices, die ich aus Threads kopiert habe. Beide kosteten mich.

Zwei Befunde, die das Audit markierte, die du nicht erwischen würdest, wenn du jedes Anthropic-Dokument von vorne bis hinten liest.

Erstens. Ich hatte einen Skill namens questionnaire-prospect mit einer Beschreibung, die 438 Zeichen lang war. Das Audit markierte ihn über der Schwelle. Nach etwa 250 Zeichen schneidet Claude Code die Beschreibung im Skill-Menü stillschweigend ab. Die vollständige SKILL.md lädt immer noch, wenn der Skill aufgerufen wird, aber im Menü, wo Claude entscheidet, ob er den Skill überhaupt auslösen soll, ist die Beschreibung verstümmelt.

Ergebnis: Claude sieht einen abgeschnittenen Satz, versteht nicht, wann der Skill feuern sollte, und ignoriert ihn stillschweigend. Der Skill stürzt nicht ab. Er hört nur auf, zuverlässig zu triggern. Ich stutzte die Beschreibung auf 223 Zeichen. Das vom Audit empfohlene Optimum sind 80 Zeichen. Keines der offiziellen Anthropic-Docs, die ich gelesen habe, erwähnt dieses Abschneideverhalten.

Was du in eine Beschreibung schreibst und was Claude tatsächlich sieht, ist nicht garantiert dasselbe.

Zweitens. Ein PostToolUse-Hook, der vitest nach jedem Edit/Write laufen lässt. TDD auf den Agenten-Workflow angewandt, nie ein kaputtes State ausgeliefert. Klang großartig auf Reddit. Klang großartig in einem Thread, den ich las.

Echtes Leben, mit einer Datei, die während eines Refactors dreißig Mal bearbeitet wurde: dreißig Testläufe. Dreißig vitest-Reports, die Claudes Kontext verschmutzen (jeder Report ist eine System-Nachricht in seinem Kontextfenster). Dreißig Latenz-Treffer. Das Audit markierte es in dem Moment, als es lief. Ich deaktivierte den Hook. Latenz bereinigt. Kontext blieb sauberer.

Die Regel, die über vitest hinausgeht: ein generischer PostToolUse-Hook, der auf Edit/Write matcht, ist fast immer eine Falle. Hooks sollten bei Phasenübergängen feuern (SessionEnd, Ende des Features, Deploy). Nicht bei atomaren Operationen.

Gemeinsamer Faden beider: generische Best Practices sind nicht dasselbe wie Best Practices für DEIN Projekt bei DEINEM Volumen. Ein Senior Dev lässt die Test-Suite nicht nach jedem Speichern laufen. Er lässt sie vor dem Commit laufen. Gleiche Logik für Agenten.

Das sind die Muster, die ich in jedem Claude Code Tutorial, das in der Produktion auseinanderfällt anprangerte. Ich hatte Best Practices wie Skills gesammelt: in einem Ordner, nur für den Fall, bezahlt in Stille.

Warum Routing die KI schärfer machte, nicht nur billiger

Das ist der Befund, den das Audit auf Platz eins setzte. Und es ist der Abschnitt, auf den der Titel zeigt.

Dreißig Tage Nutzung. 643 Sessions. 137 Millionen Token abrechenbar. Model-Mix: 94% Opus, 0% Sonnet, 4% Haiku, 2% andere.

Sonnet bei null. Bei 137 Millionen Token.

Ich hatte nicht Opus über Sonnet gewählt. Ich hatte einfach nie Routing eingerichtet. Das Audit markierte es mit einer Einsparungsprojektion von 50-75%. An den sieben Tagen, die ich im Report sichtbar habe, gab ich $1.668 aus. 50% Routing-Disziplin spart $834 die Woche. 75% spart $1.250.

Da landet der Kostenwinkel ehrlich, nicht beim Datei-Cleanup. Aber Kosten sind die halbe Geschichte. Der Schwenk, den der Titel macht, ist dieser: das Routing spart nicht nur Geld. Es macht die KI schärfer. Drei Mechanismen.

Opus hat ein Temperament. Es ist darauf getrimmt zu denken. Wenn du ihm eine begrenzte Aufgabe gibst, weitet es sie aus, weil das ist, was es gut kann. Nimm eine typische Woche. Ich debugge einen Flow in meinem WooCommerce-Store und stelle einem Explore-Agenten eine einfache Frage: "finde jede Referenz zu checkout_cta im Storefront." Eine grep-Aufgabe. Buchstäblich. Haiku macht das in vier Sekunden für einen Bruchteil eines Cents.

Im 94% Opus-Modus liest der Agent 23 Dateien, kontextualisiert die Verwendungen, bemerkt eine Inkonsistenz zwischen den Markdown-Bullet- und Blockquote-Formaten in älteren versus neueren Modulen, schlägt ein Refactoring vor, eröffnet eine Diskussion über die Faktorisierung des Musters in ein geteiltes Template. Ich hatte nichts dergleichen gefragt. Ich wollte eine Liste von Dateien. Ich bekam eine Mini-Architektur-Review. Kosten: etwa $0,30, acht Minuten, Kontext für nichts aufgefressen, weil ich weitergezogen war.

An Haiku geroutet, gleiche Abfrage: Liste in vier Sekunden, $0,001, Kontext intakt.

Opus ist hier nicht schlecht. Opus ist falsch besetzt. Opus zu bitten zu greppen ist wie einen Senior-Architekten zu bitten, Kisten in einem Schrank zu zählen.

Sonnet bei begrenzten Refactorings ist disziplinierter als Opus. Für Transformationen in einem definierten Scope, Refactoring eines Moduls, Hinzufügen eines Features innerhalb eines Perimeters, liefert Sonnet eine Ausgabe, die aligned bleibt. Weniger unaufgeforderte alternative Vorschläge. Richtiges Tool, richtiger Scope.

Opus, befreit von begrenzten Aufgaben, wird besser bei den architektonischen Entscheidungen, für die du es tatsächlich brauchst. Wenn du Opus grep UND zählen UND lookup UND architektonische Entscheidungen machen lässt, ist sein Kontext bereits verschmutzt von 47 Sessions grep, wenn du es für das harte Problem aufrufst. Die "Qualität sinkt nach 70%"-Regel lebt hier. Du bezahlst nicht nur Opus dafür, Haikus Job zu machen. Du bezahlst auch den versteckten Preis: dein Opus ist weniger scharf, wenn du es tatsächlich brauchst.

Opus bleibt die richtige Wahl für komplexes Reasoning, dafür trimmt Anthropic es. Haiku ist nicht "schlauer" absolut. Die Nuance ist, dass Haiku besser besetzt ist, bei der richtigen Aufgabe, mit sauberem Kontext.

Der Hebel, den das Audit nicht für mich ziehen konnte

Das Audit zeigt dir. Das Audit repariert nicht alles.

Von den Befunden im Report ist das Datei-Cleanup auto-anwendbar. Archiviere eine Datei, sie bleibt archiviert. Der Skill-Ballast ist teilweise auto: Beschreibungen werden vor Ort gekürzt. Der vitest-Hook ist binär, an oder aus.

Das Model-Routing? Das ist anders.

Das Tool injiziert einen Routing-Block in CLAUDE.md global mit einer 48-Stunden-TTL. Wenn ich ihn nicht auffrische, löscht er sich automatisch, weil Nutzungsmuster driften. Ich kann mich nicht aus einer Config-Datei heraus auto-disziplinieren. Ich muss bewusst dispatchen: Explore und Lookup gehen an Haiku. Refactorings im Scope gehen an Sonnet. Architektonische Entscheidungen gehen an Opus.

Das ist menschliche Disziplin. Messbar, aber nicht automatisierbar.

Die echte Botschaft des Audits ist nicht "hier sind die Dateien zum Archivieren." Sie ist näher an: hier sind die Schulden, die dein Workflow anhäuft, und der dominante Hebel läuft durch dich, nicht durch mich.

Gleiche Struktur wie etwas, das ich vor ein paar Monaten auslieferte, als ich Claude Code meine eigenen dreihundertvierundsiebzig Sessions auditieren ließ und der Report unbequem ehrlich zurückkam. /insights auditierte mein Verhalten. token-optimizer auditiert meine Config. In beiden Fällen ist die Korrektur menschlich.

Die 50-75%-Zahl ist eine Projektion zum Zeitpunkt des Audits. Mein echter Gewinn hängt von meiner Routing-Disziplin in den nächsten zwei Wochen ab. Ehrliches Framing.

Zwei Wochen später: Was die Bewertung bewegte und was nicht

Ich ließ das Audit zwei Wochen später wieder laufen. Andere Bewertung, andere Form.

Das Datei-Cleanup hielt. Die archivierten MEMORY-Dateien blieben archiviert. Die Skill-Beschreibungen blieben gestutzt. -1.386 Token pro Nachricht auf der Datei-Ebene, Baseline. -2.565 Token vom On-Demand-Korpus. Diese Gewinne brauchen keine Willenskraft. Sie sind strukturell.

Die Routing-Ebene war, wo der echte Test war. Ich hatte mich verpflichtet, Explore- und Lookup-Aufgaben an Haiku zu dispatchen, Refactorings an Sonnet, architektonische Entscheidungen an Opus. Zwei Wochen bewusstes Dispatching. Der Model-Mix verschob sich, aber nicht so sauber, wie ich es mir vorgestellt hatte. Die 48-Stunden-TTL auf dem Routing-Block in CLAUDE.md global tat ihren Job: als ich am Dienstagnachmittag zurück zu default-Opus driftete, erwischte es das Audit beim nächsten Mal, als ich es laufen ließ.

Drift-Erkennung ist das Feature, das ich unterschätzt hatte. Das Tool macht einen Snapshot deiner Config bei der Installation und beobachtet, was zurückkommt. Wenn ein Hook, den ich deaktiviert hatte, wieder installiert wird, sehe ich es. Wenn eine Memory-Datei, die ich archiviert hatte, zurückkehrt, sehe ich es auch. Der Model-Mix, der zurück zu 90% Opus rutscht, landet ebenfalls rot auf dem Dashboard.

Was ich jetzt klar sehe: die qualitative Seite ist real. Die Explore-Aufgaben, die ich an Haiku roure, kommen schneller zurück, in saubererem Kontext, und die Opus-Calls, die ich für architektonische Entscheidungen spare, kommen auf einem Kontext an, der noch nicht zerkaut wurde. Sessions, die früher 70% Füllung vor Compaction erreichten, erreichen sie jetzt ein Drittel später. Die Rechnung wird diese Änderung nicht registrieren. Die Ausgabe schon.

Ein C ist nicht "schlecht." Es bedeutet, es gibt Spielraum, und du weißt jetzt wo.

Die echten Hebel sitzen nicht da, wo Medium immer hinzeigt. Sie sitzen im Routing und in den Hooks, die du aus Threads kopierst, ohne sie auf deinem eigenen Setup zu testen.

Token-optimizer ist jetzt Teil meiner Routine, neben graphify, was eine Geschichte für einen anderen Tag ist. Ich bin ruhiger, und Claudius ist schärfer 😊

Weniger versucht, rüberzuwandern und zu checken, ob das Gras bei Codex grüner ist.

Quellen