Fokus. Flow. Ergebnisse. Was wirklich wegbricht wenn das Limit kommt.

Letzten Mittwoch. 15:00 Uhr.

Mitten im Gedanken. Mitten im Flow.

Ich arbeite an meinem persönlichen KI-Assistenten – Second Brain, 420 Dateien, alles verknüpft. Es läuft.

Dann die Warnung: Limit fast erreicht.

Ich ignoriere sie. Noch diesen einen Gedanken fertigdenken. Noch diesen einen Schritt abschließen. Zu spät – Limit erreicht.

Claude Code stoppt. Kein Weiterkommen bis nach 20:00 Uhr.

Keine Pause. Ich wechsle das Thema, fange woanders an. Aber der Kopf ist noch beim ersten Projekt. Die offenen Fragen, die halbfertigen Gedanken – die bleiben irgendwo hängen.

Nach 20:00 Uhr zurück zum Assistenten. Einlesen. Rekonstruieren. Wo war ich? Was war das nächste Problem? Was hatte ich gerade herausgefunden?

Um 23:05 Uhr bin ich fertig.

Nicht wegen mangelnder Disziplin. Nicht wegen einem schlechten Plan. Wegen einem Limit, das mich aus dem Flow gerissen hat – und mich Stunden gekostet hat, um wieder reinzukommen.

Das ist kein technisches Problem. Das ist ein Produktivitätsproblem.

Und es hat fünf konkrete Hebel, die du sofort umlegen kannst.

Hebel 1: /compact – bevor das Limit kommt, nicht danach

Die meisten warten auf die Warnung. Dann ist es zu spät.

/compact komprimiert die gesamte Konversationshistorie – ohne den Kontext zu verlieren. Claude fasst zusammen, was war. Du arbeitest weiter, als wäre nichts gewesen.

Der Trick: Nicht warten bis die Warnung kommt. Bei etwa 60% Auslastung /compact ausführen. Nach jedem abgeschlossenen Teilschritt – nicht mittendrin, nicht wenn es schon zu spät ist.

Profi-Tipp: Neues Terminal = neues Kontextfenster. Wer eine komplett neue Aufgabe startet, öffnet einfach ein frisches Terminal – Claude beginnt mit leerem Kontext und vollem Platz zum Arbeiten.

Bonus: Für Pro/Max-User ist /compact jetzt instant. Session Memory schreibt die Zusammenfassung laufend im Hintergrund – kein Warten, kein Kontextverlust.

Tipp: Bevor du /compact ausführst, sag Claude kurz was wichtig ist. „Wir haben uns entschieden, X so umzusetzen. Das soll in der Zusammenfassung erhalten bleiben.” Das kostet dich zehn Sekunden – und rettet dir den Kontext.

Hebel 2: CLAUDE.md schlank halten

Die meisten CLAUDE.md-Files sind Friedhöfe guter Absichten.

„Write clean code.” „Follow best practices.” „Be concise.” Alles drin. Nichts davon hilft Claude. Alles davon frisst Tokens – bei jeder einzelnen Session, unsichtbar im Hintergrund.

Faustregel: Für jede Zeile fragen – würde Claude ohne sie Fehler machen? Wenn nicht: löschen.

Was reingehört: Build-Commands, projektspezifische Architekturentscheidungen, Testing-Konventionen die Claude nicht selbst ableiten kann.

Was nicht reingehört: Generische Anweisungen wie „write clean code”, Dinge die Claude ohnehin richtig macht, Domain-Wissen das nur manchmal gebraucht wird.

Profi-Tipp: Detaillierte Anweisungen in separate Files auslagern und per @docs/git-instructions.md referenzieren. Claude lädt den Inhalt nur wenn relevant – nicht bei jeder Session automatisch.

Zielgröße: unter 500 Token für die Haupt-CLAUDE.md. Wer mehr hat, zahlt jeden Tag dafür – ohne es zu merken.

Hebel 3: Modell bewusst wählen

Opus ist brilliant. Und Opus frisst Tokens wie nichts anderes.

Drei Modelle, drei Einsatzgebiete:

Opus → komplexe Architekturentscheidungen, Multi-File-Refactors. Sonst nie.

Sonnet → Default für 80% der Aufgaben. Stark genug, Token-schonend.

Haiku → repetitive Tasks: Umbenennen, Formatieren, einfache Anpassungen. Schnell, günstig, unterschätzt.

Wer Opus als Default lässt, verbrennt sein tägliches/wöchentliches Budget in Stunden statt Tagen. Wechsel per /model. Zwei Sekunden. Macht den Unterschied zwischen einem langen Arbeitstag und einem, der um 15:00 Uhr endet.

Hebel 4: Nur den fehlerhaften Teil neu schreiben

Claude Code macht einen Fehler. Die häufigste Reaktion: alles nochmal von vorne.

Falsch.

Zeig Claude genau wo das Problem ist. „Nur Funktion X ist falsch – bitte nur diese neu schreiben, alles andere bleibt.” Ein vollständiger Redo bedeutet: alle Tokens nochmal. Für Code, den Claude bereits korrekt geschrieben hat.

Punktgenau korrigieren spart Token – und Zeit.

Hebel 5: Das 5-Stunden-Fenster clever nutzen

Claude Code arbeitet mit einem rollierenden 5-Stunden-Fenster. Was du am Morgen verbrauchst, ist am Nachmittag schon wieder teilweise frei.

Wer alles in einen einzigen Morgensprint packt, steht um 15:00 Uhr vor dem Limit. Wer die Arbeit auf zwei oder drei Sessions verteilt – Morgen, Mittag, Abend – arbeitet den ganzen Tag produktiv.

Große, komplexe Tasks an den Anfang einer frischen Session legen. Kleineres auf den Nachmittag.

Dein Schnell-Check

[ ] /compact bei 60% Auslastung – nicht bei 100%

[ ] Vor /compact: Claude sagen was wichtig ist

[ ] Neue Aufgabe? Neues Terminal öffnen – neues Kontextfenster, voller Platz

[ ] CLAUDE.md auf 500 Token reduzieren – alles Generische raus

[ ] Sonnet als Default setzen – Opus nur für komplexe Architektur

[ ] Fehler gefunden? Nur den fehlerhaften Teil neu schreiben – nicht alles

[ ] Arbeit auf 2–3 Sessions verteilen – 5-Stunden-Fenster clever nutzen

[ ] claude-monitor im zweiten Terminal laufen lassen – Verbrauch sichtbar machen

Diese Punkte kosten dich wenige Momente und sparen dir viel Frust und Ärger.

IMPLEMENTATION KIT

Claude Code Token-Optimierung – Cheat Sheet

Alle fünf Hebel auf einen Blick: Kontext-Management, Modell-Wahl, CLAUDE.md-Optimierung, Thinking-Tokens und Usage-Monitoring. Mit Schnell-Check für den Start jeder Session.

Einmal durchlesen. Sofort anwenden. Nie wieder um 23:00 Uhr fertigwerden.

Hol dir dein PDF Cheat Sheet oder aimadesimple.at/claude-code-cheat-sheet​

Und vielleicht schläfst du dann um 23:05 Uhr schon – statt erst fertig zu werden.

Welchen dieser Hebel setzt du heute noch um?

Kommentiere oder schreib mir direkt – ich lese alles.

Bis nächste Woche, Hans Peter

P.S. Das Limit kommt wieder. Die Frage ist nur, ob es dich wieder überrascht – oder du diesmal vorbereitet bist.