Claude Code Idle-Compaction: jetzt eine billige Zusammenfassung oder später ein kompletter Cache-Rewrite
Fünf Bedingungen entscheiden, ob die Idle-Compaction überhaupt greift, und zwei davon schließen per Default Sessions mit API-Key und die meisten mit 200K-Fenster aus. Wer sie wirklich bekommt, was der Tausch an Cache-Tokens kostet und wie du sie einstellst oder abschaltest.
Inhalt
Claude Code 2.1.299, erschienen am 14. Oktober, bringt ein Feature mit, das du nie aufrufst. Lässt du eine große Unterhaltung im Terminal etwa 54 Minuten liegen, kompaktiert Claude Code sie von selbst, ein paar Minuten bevor der einstündige Prompt-Cache abliefe. Laut Settings-Referenz zeigt die Unterhaltung bei deiner Rückkehr diesen Hinweis:
Compacted while idle, before the prompt cache expiredDie Release Note verkauft das als ersparte Neuverarbeitung. Das stimmt, und es ist zugleich eine Entscheidung, die jemand für dich trifft, mit Kosten, die du messen kannst, und einem Verlust, den du nicht messen kannst. Seltsam ist, wer das Feature bekommt. Per Default läuft es für Abonnenten innerhalb des Kontingents ihres Plans, und die zahlen in Quota, zu einem Wechselkurs, den Anthropic nicht veröffentlicht. Wer die Ersparnis in Dollar sehen würde, also Nutzer mit API-Key, bleibt außen vor, außer er zahlt für jeden Cache-Write das Doppelte des Basis-Inputpreises. Und was auch immer es spart: Die Zusammenfassung, die deine Historie ersetzt, entsteht jetzt, während niemand hinschaut.
Das Idle-Verhalten selbst ist dokumentiert, nicht beobachtet. Ausgeführt habe ich nur den TTL-Check weiter unten, auf 2.1.300.
Was macht die Idle-Compaction in Claude Code eigentlich?
Sie zieht den normalen Compaction-Schritt vor, solange der Cache noch warm ist. Compaction schickt die ganze Unterhaltung plus eine Anweisung zum Zusammenfassen als einen einzigen Request. In Minute 54 ist dieses Präfix noch gecacht, also liest der Request es zum Cache-Read-Preis. In Minute 61 wäre es das nicht mehr, und was immer du als Nächstes schickst, verarbeitet die komplette Historie neu.
Die Seite zum Prompt Caching sagt es direkt: Nach einer Pause, die länger ist als die Lebensdauer des Caches, verarbeitet der Zusammenfassungs-Request die komplette Historie als ungecachten Input neu („reprocesses the full history as uncached input“). Die Idle-Compaction verlegt das Zusammenfassen auf den letzten billigen Moment.
Wann greift die Idle-Compaction in Claude Code?
Nur wenn fünf Bedingungen aus der Settings-Referenz gleichzeitig erfüllt sind. Die Session ist eine interaktive Terminal-Session. Ein claude -p-Lauf oder eine Agent-SDK-Session bekommt sie also nie. Die Unterhaltung läuft mit der einstündigen Prompt-Cache-TTL, und genau diese Bedingung siebt die meisten aus. Claude Code kann Feature-Flags von Anthropic abrufen. DISABLE_GROWTHBOOK=1 oder CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC schalten das ab und die Idle-Compaction gleich mit. Der Kontext hat die Schwelle erreicht, per Default 200.000 Tokens. Und seit dem letzten Request sind etwa 54 Minuten vergangen, wobei der Rechner zu diesem Zeitpunkt wach sein muss: Ein Laptop, der Minute 54 verschläft, kompaktiert nicht.
Meine eigenen Agents laufen als interaktive Claude-Code-Sessions in tmux mit einem Max-Abo. Die erste Bedingung gilt für sie also, die zweite, solange sie im Kontingent des Plans bleiben. Genau dieses Profil wählen die Bedingungen aus. Ein Team, das Headless-Jobs mit API-Keys fährt, bekommt nichts davon.
Welche Claude-Code-Sessions laufen mit der einstündigen Cache-TTL?
Per Default nur die Hauptunterhaltung in einem Claude-Abo innerhalb des im Plan enthaltenen Kontingents. Die Prompt-Caching-Seite listet die Fälle auf: Im Abo bekommt die Hauptunterhaltung eine Stunde, mit API-Key, Usage Credits oder einem Cloud-Provider fünf Minuten. Subagents, Workflows und die Compaction selbst bekommen in beiden Fällen fünf Minuten, abgesehen von ein paar Hilfs-Requests, die Anthropic serverseitig auf eine Stunde setzt. Sobald ein Abo über sein Planlimit hinausgeht und Usage Credits verbraucht, setzt Claude Code die Hauptunterhaltung per Default auf fünf Minuten, und die Idle-Compaction greift nicht mehr, außer du hast die TTL selbst festgelegt.
Welche TTL ein Request nutzt, kannst du prüfen, ohne eine Stunde zu warten. Die Doku schlägt einen einzelnen Lauf vor:
claude -p "Reply with the single word: ok" --output-format jsonAuf 2.1.300 mit Abo kam der usage-Block mit allen Cache-Writes mit einstündiger Lebensdauer zurück:
"cache_creation": {
"ephemeral_1h_input_tokens": 34503,
"ephemeral_5m_input_tokens": 0
}Ein -p-Lauf fällt in dieselbe Kategorie „Hauptunterhaltung“ wie deine interaktiven Turns, er zeigt also, welcher Default für deine Abrechnung gilt. Landen die Writes in ephemeral_5m_input_tokens, qualifizieren sich auch deine interaktiven Sessions nicht, bis du die TTL änderst. Mit API-Key aktivierst du die Idle-Compaction, indem du die Hauptunterhaltung auf eine Stunde stellst:
{
"promptCacheTtl": "1h"
}Gratis ist das nicht. Einstündige Cache-Writes kosten das Zweifache des Basis-Inputpreises, fünfminütige das 1,25-Fache, und die Doku warnt, dass sich die längere TTL bei kurzen Arbeitsschüben, die nie länger als fünf Minuten ruhen, nicht rechnet.
Passt die 200K-Schwelle von Claude Code zu deinem Kontextfenster?
Nur bei einem Fenster mit 1M Tokens. Bei 200K greift der Default fast nie. Die Auto-Compaction in einem 200K-Fenster läuft, bevor die Unterhaltung 200.000 Tokens erreicht, also wird eine Unterhaltung dort selten groß genug, und die Settings-Referenz empfiehlt für solche Sessions, die Schwelle auf 150.000 zu senken. Modelle mit nativem 1M-Fenster, darunter Opus 5.5, Sonnet 5 und neuer, Haiku 5.5 und die Fable-Modelle, kompaktieren automatisch erst bei etwa 967K, dort greift der 200K-Default also. Mein TTL-Check meldete für Opus 5.5 contextWindow: 1000000.
Die Schwelle setzt du im env-Block einer Settings-Datei. Werte unter 100.000 werden auf 100.000 angehoben, das ist das Minimum:
{
"env": {
"CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS": "150000"
}
}Laut Release Note brauchen die Variable und das Setting 2.1.290 oder neuer, das Feature selbst kam aber erst mit 2.1.299, und die Lücke wird nicht erklärt. Führ claude --version aus und rechne mit 2.1.299 als tatsächlichem Minimum.
Was kostet die Idle-Compaction in Claude Code im Vergleich zur kalten Rückkehr?
Rein auf das alte Präfix bezogen ist die warme Zusammenfassung grob 40-mal billiger als ein kalter Rewrite, aber das ist nicht die ganze Rechnung. Nimm eine Unterhaltung mit 200K Tokens auf Opus 5.5 und rechne in Einheiten des Basis-Inputpreises, mit den von Anthropic veröffentlichten Multiplikatoren:
| Weg | Was mit dem 200K-Präfix passiert | Einheiten |
|---|---|---|
| Idle-Compaction in Minute 54 | aus dem Cache gelesen zum 0,05-Fachen des Basispreises (Opus 5.5 und Sonnet 5.5; bei den meisten anderen Modellen 0,1) | etwa 10K |
| Rückkehr in Minute 70, keine Compaction | neu geschrieben zum Einstundensatz, dem 2-Fachen des Basispreises | etwa 400K |
Die 10K sind nur der Read. Die Idle-Compaction zahlt außerdem die Output-Tokens der Zusammenfassung, und der nächste Turn baut einen kürzeren Kontext neu auf: die Zusammenfassung plus Anweisungen, Memory, Dateien und Skills, die Claude Code nach jeder Compaction wiederherstellt. Ein Teil davon trifft den bestehenden System-Prompt-Cache, der Rest wird neu geschrieben. Die echte Ersparnis liegt also unter dem 40-Fachen, und wie weit darunter, hängt davon ab, wie viel wiederhergestellt wird.
Zwei weitere Einschränkungen. Im Abo innerhalb des Plankontingents wird nichts davon in Dollar abgerechnet. Es ist Quota, und Anthropic veröffentlicht nicht, wie die Quota Cache-Reads gegen Writes gewichtet. Und der billige Weg lohnt sich nur, wenn du zurückkommst. Eine Session, die ein Timer zur vollen Stunde beendet oder die du nicht wieder aufnimmst, zahlt für eine Zusammenfassung, die niemand liest.
Was verliert eine Compaction-Zusammenfassung in Claude Code?
Die wörtliche Unterhaltung im Arbeitskontext des Modells. Das Session-Protokoll auf der Platte bleibt erhalten; was sich ändert, ist das, was Claude im nächsten Turn sieht. Laut der Doku zum Kontextfenster behält die Zusammenfassung deine Anfragen und Absichten, zentrale technische Konzepte, gelesene oder geänderte Dateien mit wichtigen Ausschnitten, Fehler und ihre Fixes, offene Aufgaben und die aktuelle Arbeit. Vollständige Tool-Ausgaben und Zwischenüberlegungen fallen aus dem Kontext.
Die Basisanweisungen und der Output-Stil gelten nach der Compaction weiter. Claude Code lädt die CLAUDE.md im Projekt-Root, Rules ohne Pfadbindung und die Auto-Memory von der Platte neu, liest bis zu fünf zuletzt geänderte Dateien, die es angefasst hat, erneut ein (eine Datei über 5.000 Tokens kommt nur als Pfad zurück), injiziert die Inhalte der Skills, die du aufgerufen hast, erneut (gedeckelt auf je 5.000 Tokens und insgesamt 25.000, die ältesten fliegen zuerst raus) und hängt die Ausgabe von SessionStart-Hooks an, die auf die Quelle compact passen. Rules mit paths:-Frontmatter und verschachtelte CLAUDE.md-Dateien verschwinden mit der Historie in der Zusammenfassung und werden erst wieder geladen, wenn Claude eine passende Datei anfasst.
Was eine Compaction überstehen muss, ob idle oder nicht, gehört also in eine Rule ohne Pfadbindung, in die CLAUDE.md im Projekt-Root oder in einen SessionStart-Hook auf compact. Eine Entscheidung, die du nur im Chat getroffen hast, ist genau das, was eine Zusammenfassung paraphrasiert. Ich habe schon argumentiert, dass die nach der Compaction zurückgespielte Zusammenfassung ein Input ist, den man vorsichtig behandeln sollte, kein Spielstand, und bei der Idle-Compaction bist du nicht einmal dabei, wenn sie entsteht.
Einen Fall lässt die Doku offen. Die Idle-Zeit wird ab dem letzten Request gemessen, und Hintergrundbefehle laufen über eine Compaction hinweg weiter, aber nirgends steht, ob ein laufender Hintergrundbefehl oder ein anstehendes geplantes Wakeup den Idle-Timer aufhält. Wenn du Sessions auf langen Builds parkst, lohnt sich ein Test, bevor du dich in die eine oder andere Richtung darauf verlässt.
Wie schaltest du die Idle-Compaction in Claude Code ab?
"idleCompaction": false in einer beliebigen Settings-Datei schaltet nur die Idle-Compaction ab (2.1.290 oder neuer; auf älteren Versionen stattdessen autoCompactEnabled abschalten). DISABLE_AUTO_COMPACT=1 schaltet Idle-Compaction und normale Auto-Compaction zusammen ab, übrig bleibt nur ein manuelles /compact. Weil idleCompaction in jeder Settings-Datei funktioniert, kannst du es für ein einzelnes Projekt in .claude/settings.local.json abschalten und überall sonst anlassen:
{
"idleCompaction": false
}Meine Einschätzung, nicht gemessen: Lass es an, wo die Arbeit in den Dateien steckt, etwa beim Coden und bei Wartung, denn Zusammenfassung plus neu gelesene Dateien tragen das meiste, was zählt. Schalte es ab oder heb die Schwelle an, wo der Wert im Gesprächsfaden selbst liegt, etwa bei einer langen Argumentation oder einer Designdiskussion, die du mitten im Satz wieder aufnehmen willst. Dort ist die Input-Ersparnis gering im Vergleich zu einer paraphrasierten Entscheidung.
Wie misst du die Idle-Compaction in Claude Code mit OpenTelemetry?
Schalte den OpenTelemetry-Exporter ein und lies die claude_code.api_request-Events. Am schnellsten geht es lokal mit Ausgabe auf die Konsole:
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=console
export OTEL_METRICS_EXPORTER=consoleDu brauchst drei Attribute. query_source nennt das Subsystem, das den Request geschickt hat, und compact markiert Compaction-Aufrufe, idle oder nicht. Kombiniere es also mit der Zeit seit deinem vorherigen Request und dem Hinweis im Transkript. cache_read_tokens auf diesem Aufruf zeigt, ob er warm gelesen hat. Und 2.1.300 hat cache_creation_5m_tokens und cache_creation_1h_tokens ergänzt, die Cache-Writes nach Lebensdauer aufteilen. Diese Aufteilung steht in den Release Notes zu 2.1.300, die Monitoring-Referenz listet nur das kombinierte cache_creation_tokens. Eine warme Idle-Compaction sieht aus wie ein compact-Request mit großem Cache-Read, gefolgt von einem Turn, der den deutlich kleineren kompaktierten Kontext schreibt. Ein großer einstündiger Write bei deiner ersten Nachricht nach der Rückkehr passt zu einem verpassten Zeitfenster, aber ein Modellwechsel oder ein geändertes Präfix erzeugt dieselbe Signatur, also prüf diese beiden, bevor du der Uhr die Schuld gibst.
Ohne OpenTelemetry zeigt /usage eine Zeile Prompt cache (main) mit der Trefferquote der Session, der Zahl der Misses und ob der Cache gerade warm ist (2.1.251 oder neuer), und ab 2.1.260 nennt es die wahrscheinliche Ursache des letzten Misses. Auf der API-Seite unterscheidet die Cache-Diagnose einen geänderten Prompt von einem unveränderten, dessen Cache-Eintrag einfach weg war.
Was solltest du bei der Idle-Compaction in Claude Code zuerst prüfen?
Mach den einmaligen TTL-Check. Sind deine Writes fünfminütig, bringt dir das Feature nichts, und die einzige Frage ist, ob sich einstündige Writes für dich lohnen. Sind sie einstündig, schau auf dein Kontextfenster: Bei 200K senkst du die Schwelle oder akzeptierst, dass es selten greift. Dann entscheide pro Projekt, ob dir eher der Gesprächsfaden oder die Dateien fehlen würden. Eine Zusammenfassung aus Minute 54 ist billig, und sie ist zugleich das eine Stück Kontext, das niemand geprüft hat, bevor die Session weiterlief.
01 / Diskussion
Hier gibt es keine Kommentarspalte. Diskussionen laufen auf X.
02 / Weitere Artikel
Gemini 4 Argon ist öffentlich: die Einsätze, die Google am ersten Tag meldet, und der Preis, der sich am 1. Dezember verdoppelt
Sieben Einsätze, die Google für Argon meldet, jeweils mit dem Beitrag, aus dem sie stammen, und der einzige, der sein Review-Protokoll zeigt: sechs Vorschläge, zwei ausgeliefert. Der Rest ist die Rechnung, die nicht in der Ankündigung steht, sondern in der Doku, angefangen damit, wie Long Decode den Input zählt.
Claude Managed Agents Dynamic Workflows: Der Agent schreibt den Fan-out, das Budget muss vorher stehen
Mit dem neuen multiagent-Typ ist der Schalter standardmäßig an, den Start eines Runs genehmigt niemand, und die einzige Kostengrenze lässt sich nur beim Anlegen der Session setzen. Eine Einrichtungsanleitung auf Basis der Dokumentation, mit den drei Einstellungen, die vor der ersten Nachricht entschieden sein müssen.
Verwaltete Git-Worktrees in der Codex CLI: drei Wege, einen zu starten, und das Tool des Modells beginnt beim Standard-Branch des Remotes
Ein praktischer Durchlauf mit Codex CLI 0.162.1 in einem Wegwerf-Repository: wo die Checkouts landen, bei welchem Commit jeder Einstieg beginnt, warum deine .env und deine nicht committeten Änderungen zurückbleiben, wie du die Arbeit zurückholst und was das Aufräumen auf der Platte hinterlässt.