Claude Code Autocompact: Window, /compact und /clear

Die Session läuft seit Stunden, der Agent liefert, und irgendwann fragst du dich, warum eine einzeilige Rückfrage so viel an deinem Kontingent zieht. Die Antwort steht in der Claude-Code-Doku: Jeder Request schickt die komplette Konversation mit, und jede Tool-Runde ist ein weiterer Request mit allen bisherigen Tool-Ergebnissen. Prompt Caching macht das billiger, aber nicht kostenlos. Mit einem 1M-Kontextfenster wird dieser Schwanz lang, denn auf solchen Modellen kompaktiert Claude Code standardmäßig erst bei etwa 967K Tokens.

Das betrifft laut Doku alle Modelle mit nativem 1M-Fenster: die Fable-Modelle, Sonnet 5 und neuer, Haiku 5.5 sowie Opus 4.7 und neuer. Wer nichts einstellt, bezahlt das Ende langer Sessions am teuersten.

Wo du das Auto-Compact-Window setzt

Das Auto-Compact-Window legt fest, wie voll der Kontext werden darf, bevor Claude Code die ältere Historie zusammenfasst. Es gibt vier Stellen dafür, und die Reihenfolge ist wichtig:

# Für das aktuelle Modell, landet unter modelSettings in den User-Settings
/autocompact 400k
/autocompact auto          # zurück zum für das Modell getunten Wert

# Für einen einzelnen Start, ohne die gespeicherte Einstellung anzufassen
claude --autocompact 300k

# Für Skripte, CI und Cloud-Umgebungen
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000

// ~/.claude/settings.json – gilt für alle Modelle
{
  "autoCompactWindow": 400000
}

Ein paar Details, die im Alltag stolpern lassen:

• Ein per /autocompact gespeicherter Modellwert schlägt autoCompactWindow in derselben Datei. Vor v2.1.288 hat der Befehl noch einen globalen Wert geschrieben.
• Setzen Managed Settings ein eigenes Window, speichert /autocompact deinen Wert zwar, die Session nutzt aber den höher priorisierten. Das Flag --autocompact wird dagegen nicht verdrängt.
• Die Env-Variable gewinnt gegen Befehl, Flag und Setting. Solange sie gesetzt ist, sagt used_percentage in der Status Line nichts mehr darüber, wann kompaktiert wird, weil der Wert gegen das volle Fenster des Modells rechnet.
• Erlaubt sind 100K bis 1M, als 200000, 500k oder als Kurzform 200 für 200.000. Gedeckelt wird immer beim Kontextfenster des Modells.
• Für einzelne Subagents lässt sich ein eigenes Window setzen. Wie Subagents Kontext isolieren, steht im Artikel zur Subagent-Architektur.

Willst du grundsätzlich bei 200K bleiben, setzt du CLAUDE_CODE_DISABLE_1M_CONTEXT=1. Dann gelten auch 1M-Modelle als 200K-Modelle, und ein höheres Auto-Compact-Window hebt das nicht auf.

Was ein kleineres Window bringt, und was es kostet

In einer Diskussion auf Reddit hat ein Entwickler das Window für seine eigene Arbeit auf 400K gesetzt und Vorher und Nachher verglichen, nur den Main-Thread. Bei ihm entfielen vorher 68 % der Main-Thread-Kosten auf Requests mit mehr als 400K Kontext. Danach sank der Kontext pro Request im Mittel von 415K auf 220K, die Kosten pro Request um 43 %, gemessen in nach API-Raten gewichteten Tokens.

Er ordnet die Zahl selbst ein: Vorher und Nachher waren unterschiedliche Zeiträume mit unterschiedlicher Arbeit, kein kontrolliertes Experiment. Ein Replay derselben Sessions mit Kompaktierung bei 400K ergab −27 bis −40 %, was er für die ehrlichere Zahl hält. Ein Kommentator ergänzt, dass ein Replay die Zusatzkosten nicht abbildet, wenn das Modell nach jeder Kompaktierung Dateien neu liest.

Die Gegenseite ist real. Statt 16 Zusammenfassungen im Monat waren es 75 in einer Woche, jede rund 76 Sekunden, zusammen 95 Minuten Warten. Und nach einer Zusammenfassung liest das Modell oft Dateien erneut, die es schon kannte. Seine Faustregeln: Erreichen deine Sessions selten 400K, ändert das Window nichts. Bleibst du stundenlang in einer Session, können 200K bis 300K lohnen.

Sliding statt Zusammenfassen

Der interessantere Teil des Threads: Der Großteil des Kontexts ist alter Tool-Output, also Datei-Reads, Testläufe und Diffs. Statt bei der Kompaktierung ein Modell zusammenfassen zu lassen, ersetzt ein Hook alte Tool-Ausgaben durch eine kurze Notiz nach dem Muster „schon gesehen, bei Bedarf neu lesen“ und lässt die Konversation selbst wörtlich stehen. Ohne Modell-Call dauert das Millisekunden, die Zusammenfassung bleibt Fallback für /compact und für Fälle, in denen Sliding nicht genug freiräumt. Der Autor hat das als MIT-lizenziertes Plugin namens tokendoctor veröffentlicht.

In seinem Benchmark auf Haiku 5.5 mit 100K-Window lag Sliding bei einem langen Arbeitstag bei −19 % Kosten und −33 % Zeit, bei einem Eval-Harness bei −35 % und −28 %. Bei einer kurzen Aufgabe mit nur einer Kompaktierung kostete es 6 % mehr und sparte 17 % Zeit. Alle Tests liefen in beiden Modi grün.

Der Haken, den ein Kommentar sofort anspricht: Wer alte Tool-Ausgaben ersetzt, ändert den Prompt-Prefix, ab der ersten ersetzten Ausgabe wird neu gecacht. System Prompt und Tool-Definitionen bleiben laut Autor im Cache. Die Claude-Code-Doku zählt solche Umbauten, ob durch Kompaktierung oder durch das Leeren alter Tool-Ergebnisse, als erwarteten Rebuild und nicht als normalen Cache Miss. Wie du lauten Output gar nicht erst in den Kontext lässt, zeigt der Artikel zu Stack Traces und Test-Output.

/compact, /clear und Kontext-Budget

Die Doku gibt eine klare Arbeitsteilung vor:

• /clear zwischen unabhängigen Aufgaben. Veralteter Kontext kostet bei jeder weiteren Nachricht. Vorher /rename, damit du die Session mit /resume wiederfindest. /clear selbst kostet nichts.
• /compact mit Anweisung, wenn du Kontinuität brauchst. Etwa /compact Focus on code samples and API usage. Bedenke: /compact liest die ganze Konversation, die es zusammenfasst. Auf großem Kontext ist das selbst ein großer Request.
• /context und /usage als Messinstrumente. /context zeigt, was gerade Platz frisst, /usage schlüsselt auf Abo-Plänen auf, wo deine Nutzung hingeht.

Was das für deinen Workflow bedeutet

Das Auto-Compact-Window ist kein globaler Sparregler, sondern eine Einstellung pro Arbeitsweise. Miss zuerst, ob deine Sessions überhaupt in die teure Zone kommen. Wenn ja, setz pro Modell per /autocompact einen Wert und in CI die Env-Variable, damit dort reproduzierbar dasselbe gilt. Rechne die Wartezeit und das erneute Lesen von Dateien gegen die Ersparnis. Und gewöhn dir /clear an, sobald die Aufgabe wechselt: Das ist der einzige Schritt, der garantiert nichts kostet.

Prüf außerdem, ob ein Hook große Tool-Ausgaben schon beim Entstehen kürzen kann, wie im Hooks-Guide beschrieben. Was nie im Kontext landet, muss später auch nicht kompaktiert werden.

Du willst wissen, ob Window, Settings-Scopes und Hooks in deinem Repo zusammenpassen? Frag ein Agent-Setup-Review an, das deine settings.json und CLAUDE.md auch auf Kontext-Disziplin prüft.