Das 5-Stunden-Fenster optimal nutzen

Auf einen Blick (Kurzfassung):

Start-Timing: Deine erste Frage startet den 5-Stunden-Timer – nutze das gezielt für deine Arbeitsblöcke.
Session-Hygiene: Beende Sessions mit /clear, sobald ein Feature fertig ist, um Kontext-Ballast abzuwerfen.
Warmer Cache: Arbeite an zusammenhängenden Tasks am Stück, solange der Cache aktiv ist.

Die Ausgangslage

Aus Artikel 2: Das Session-Fenster wird mit deiner ersten Nachricht angelegt und nach fünf Stunden zurückgesetzt. Darüber liegt ein Wochenlimit mit festem Reset-Zeitpunkt. Absolute Zahlen veröffentlicht Anthropic nicht.

Daraus folgen drei Strategien, die sich gegenseitig verstärken:

1. Timing

Das Fenster bewusst starten, statt es zufällig zu verbrennen.

2. Session-Hygiene

Nicht die Uhr ist das Problem, sondern der mitgeschleppte Kontext.

3. Cache-Wärme

Innerhalb des Fensters keine unnötigen Cache-Invalidierungen produzieren.

1. Timing: das Fenster bewusst starten

Diese Sektion beruht auf einer Ableitung, nicht auf einem Zitat. Dass das Fenster mit der ersten Nachricht startet, folgt aus der Restlaufzeit-Anzeige in Settings → Usage — siehe die Notiz in Artikel 2. Prüfe es an deinem eigenen /usage: verhält sich das Fenster anders, verwirf die Timing-Empfehlungen. Die beiden folgenden Strategien — Session-Hygiene und Cache-Wärme — gelten unabhängig davon.

Weil das Fenster mit der ersten Nachricht anfängt, ist die teuerste Gewohnheit die triviale Frage am frühen Morgen. Wer um 8:00 Uhr fragt „ist das Deployment durchgelaufen?" und um 10:00 Uhr mit der eigentlichen Arbeit beginnt, hat 40 % des Fensters verschenkt.

Praxis: Erst die Arbeit vorbereiten — Ticket lesen, Repo öffnen, Kontext im Kopf sortieren — dann Claude Code starten. Der erste Prompt sollte der erste echte Arbeitsauftrag sein.

Zwei Fenster pro Arbeitstag denken

Fünf Stunden Fenster, acht Stunden Arbeitstag: es passen zwei Fenster hinein, wenn man sie sauber setzt. Etwa Fenster A ab 9:00, Fenster B ab 14:00. Die Lücke dazwischen ist der natürliche Platz für Code-Review, Meetings und das Lesen dessen, was Claude gebaut hat.

Fragen, die keine Arbeit sind, sammeln und ins laufende Fenster legen — nicht als Fensterstarter verwenden. /btw ist dafür ideal: die Antwort erscheint in einem Overlay und landet nie in der Konversationshistorie, kostet also auch in allen folgenden Turns nichts.

Vor dem Fensterstart wissen, wo man steht

/usage        # Plan-Balken, Aufschlüsselung; d/w für 24h bzw. 7 Tage

Für dauerhafte Sichtbarkeit lohnt sich eine Statusline mit den rate_limits-Feldern plus Kontextauslastung. Man sieht dann beides gleichzeitig: wie voll das Kontextfenster ist und wie viel Kontingent noch da ist.

2. Session-Hygiene: Kontext ist das eigentliche Kostenmodell

Die Uhr allein verbraucht nichts. Was verbraucht, ist die Menge an Tokens pro Turn — und die wächst monoton, solange die Session offen ist.

`/clear` ist kostenlos, `/compact` nicht

/clear erzeugt keinen API-Request. /compact muss die Konversation, die es zusammenfasst, erst lesen — bei großem Kontext ist das selbst ein teurer Request.

Situation	Richtiges Werkzeug
Nächste Aufgabe hat nichts mit der letzten zu tun	`/clear` — vorher `/rename`, damit die Session per `/resume` wiederfindbar bleibt
Gleiche Aufgabe, aber Historie ist voll	`/compact <Anweisung>` an einer natürlichen Pause, nicht mitten in der Arbeit
Ein Weg soll komplett verworfen werden	`/rewind` — kürzt auf einen bereits gecachten Präfix zurück, statt einen neuen zu bauen
Nur ein Teil der Konversation stört	Esc + Esc → Checkpoint wählen → „Summarize from here" / „Summarize up to here"
Kurze Nebenfrage	`/btw` — landet nie in der Historie

Nach zwei erfolglosen Korrekturen: neu starten

Wenn du Claude zweimal beim selben Punkt korrigiert hast, ist der Kontext mit gescheiterten Ansätzen verschmutzt. Eine saubere Session mit einem besseren Prompt schlägt eine lange Session mit angesammelten Korrekturen fast immer — und kostet weniger.

Spec und Implementierung trennen

Ein Muster, das Kontingent und Qualität gleichzeitig verbessert: In einer ersten Session Claude per AskUserQuestion interviewen lassen und eine SPEC.md schreiben. Dann neue Session starten, die nur noch implementiert. Die zweite Session hat sauberen Kontext, die Spezifikation liegt auf der Platte statt in der Historie.

3. Cache-Wärme: Invalidierungen im Fenster vermeiden

Im Abo fordert Claude Code automatisch die 1-Stunden-Cache-TTL an, und jeder Treffer setzt den Timer zurück. Solange du arbeitest, bleibt der Cache warm. Das ist der stärkste stille Hebel innerhalb eines Fensters — Cache-Reads kosten rund 10 % des normalen Input-Preises.

Der teure Moment ist die Rückkehr. Die erste Nachricht nach einer Pause, die länger als die Cache-Lebensdauer ist, verarbeitet den kompletten Kontext neu. Wenn du weißt, dass du zwei Stunden weg bist: /clear vorher, oder gleich mit einer neuen Session zurückkommen. Eine sehr lange Session nach einem Claude-Code-Upgrade fortzusetzen ist laut Docs der teuerste Request überhaupt, weil die Historie hinter einem anderen System-Prompt liegt.

Innerhalb des Fensters nicht umschalten

Kein /model-Wechsel mitten in der Aufgabe. Jedes Modell hat einen eigenen Cache. Wer „mit Opus planen, mit Sonnet ausführen" will, nimmt besser zwei parallele Sessions als einen Wechsel — sonst zahlt jeder Wechsel die ganze Historie neu.
Kein /effort-Wechsel. Der Cache ist auch nach Effort geschlüsselt.
Fast Mode früh entscheiden. Das Einschalten kostet einmal pro Konversation die volle Historie — früh in der Session ist das günstig, spät teuer.
MCP-Server vorher aufräumen. Ein Server, der mitten in der Session neu verbindet, kann den Cache invalidieren, sofern seine Tools nicht deferred sind.

Ausnahme opusplan: Diese Modell-Einstellung wechselt beim Betreten und Verlassen des Plan Mode zwischen Opus und Sonnet. Jeder Toggle ist damit ein Modellwechsel und startet einen frischen Cache. Wer im Fenster oft zwischen Plan und Ausführung springt, fährt mit einem festen Modell günstiger.

Die teuren Betriebsarten dosieren

Nichts frisst ein Kontingent so schnell wie unkontrollierte Parallelität. @ClaudeDevs musste einmal alle Limits zurücksetzen, weil ein Bug Sessions dazu brachte, exzessiv parallele Subagents zu spawnen.

Betriebsart	Empfehlung fürs Fenster
Agent Teams (≈ 7 × Tokens)	Nur für abgegrenzte, wirklich parallele Arbeit. Teams klein halten, Sonnet für Teammates, Spawn-Prompts knapp, Teammates beenden, sobald fertig.
Subagents	Gut für verbose Recherche — der Output bleibt in ihrem Kontext. Aber: 5-Minuten-TTL statt 1 Stunde, auch im Abo.
Scheduled Tasks	Feuern auch bei idler Session und senden den vollen Kontext. In einem knappen Fenster abschalten.
Opus als Default	Laut Docs eine der zwei häufigsten Ursachen für unerwartet hohen Verbrauch — die andere sind Sessions, die nie geleert werden.

Das Wochenlimit ist die eigentliche Decke

Das 5-Stunden-Fenster ist ärgerlich, aber es ist nach fünf Stunden weg. Das Wochenlimit ist bis zum festen Reset-Zeitpunkt weg. Ein einzelner intensiver Tag kann das Wochenkontingent aufbrauchen, obwohl das Session-Fenster noch Luft hätte.

Konsequenz: über die Woche verteilen statt in zwei Tage stopfen. Wer /usage mit w auf die 7-Tage-Ansicht schaltet, sieht früh genug, ob der aktuelle Verbrauch bis zum Wochenreset trägt.

Beim Opus-Limit gilt eine Ausnahme: Es ist modellspezifisch. „You've hit your Opus limit" bedeutet nicht Feierabend, sondern /model → Sonnet.

Wenn es trotzdem eng wird

Usage Credits (/usage-credits) lassen dich über das Kontingent hinaus arbeiten. Bewusst sein: sobald Credits laufen, wird pro Token abgerechnet, und Claude Code senkt die Cache-TTL automatisch auf fünf Minuten — die Kosten pro Turn steigen dadurch zusätzlich.
Modell herunterstufen hilft nur beim Opus-Limit, nicht bei Session- oder Wochenlimit.
Effort senken reduziert Thinking-Tokens, die als Output abgerechnet werden — wirkt also auch bei knappem Kontingent.

Tagesrhythmus als Vorlage

Zeit	Aktion	Warum
vor dem Start	Ticket lesen, `/usage` prüfen, Modell und Effort festlegen	Fenster nicht mit Aufwärmen verbrennen; keine Wechsel später
Prompt 1	Die eigentliche Aufgabe, vollständig spezifiziert, mit Verifikationsziel	Startet das Fenster produktiv, spart Rework
laufend	`/clear` zwischen unzusammenhängenden Aufgaben, `/btw` für Nebenfragen	Kontext klein halten; Cache bleibt warm
lange Pause	`/rename` + `/clear`, später `/resume`	Vermeidet den teuren Cache-Miss beim Zurückkommen
Fensterende	Review, Merge, Doku — ohne Claude	Fenster B nicht anfangen, solange Fenster A noch offen ist
wöchentlich	`/usage` mit `w`	Das Wochenlimit ist die härtere Decke