Claude Code Context Buffer

Du triffst 167K Tokens. Claude compactet. Kontext geht verloren. Jedes. Mal.

Das nervige daran: Ein Teil deines Kontextfensters ist gesperrt, reserviert von Claude Code selbst. Dieser Anteil betrug früher 45.000 Tokens (22,5% von 200K). Anfang 2026 sank der Buffer auf rund 33.000 Tokens (16,5%), was etwa 12K mehr Tokens für echte Arbeit freigibt.

Diese Änderung wurde im offiziellen Claude Code-Changelog nicht angekündigt. Der nächste Hinweis ist v2.1.21: "Fixed auto-compact triggering too early on models with large output token limits", was die Buffer-Berechnung wahrscheinlich neu justiert hat. Online-Posts und Docs werfen noch die 45K-Zahl rum, aber /context zeigt bei aktuellen Versionen 33K.

Der Buffer ist aus gutem Grund da. Zu wissen, wie er genau funktioniert, trennt Leute, die gegen das System kämpfen, von denen, die damit arbeiten.

Lies diese Seite, wenn der Buffer selbst die Frage ist: wann Compaction auslöst, warum der reservierte Bereich existiert und welche Umgebungsvariablen wirklich was ändern. Wenn du den breiteren Workflow-Einfluss des größeren Fensters willst, lies 1M Context Window in Claude Code. Wenn du praktische Regeln willst, wann du in einer Session bleiben vs. sie resetten sollst, lies Context Management.

Wie Auto-Compaction wirklich funktioniert

Claude Code überwacht die Kontextauslastung kontinuierlich. Bei etwa 83,5% des Gesamtfensters (hoch von ~77-78% vorher) löst Auto-Compaction aus.

So läuft die Sequenz ab:

1. Claude fasst deine Konversationshistorie zusammen
2. Ältere Nachrichten werden durch eine kondensierte Zusammenfassung ersetzt
3. Du verlierst granulare Details aus dem frühen Teil der Session
4. Die Session läuft mit reduziertem Kontext weiter

Bei einem 200K-Fenster landet Compaction irgendwo bei 167K Tokens echter Nutzung. Die 33K Buffer sitzen nicht untätig rum. Claude gibt sie für die Zusammenfassung selbst aus.

Der /context-Befehl

Starte /context, um genau zu sehen, wo deine Tokens hingehen:

claude-opus-4-5-20251101 · 76k/200k tokens (38%)

System prompt: 2.7k tokens (1.3%)
System tools: 16.8k tokens (8.4%)
Custom agents: 1.3k tokens (0.7%)
Memory files: 7.4k tokens (3.7%)
Skills: 1.0k tokens (0.5%)
Messages: 9.6k tokens (4.8%)
Free space: 118k (58.9%)
Autocompact buffer: 33.0k tokens (16.5%)

Die Messages-Zeile ist deine Konversationshistorie. Beobachte, wie sie steigt. Wenn Free Space auf null fällt (Buffer eingeschlossen), feuert Compaction.

Warum der Buffer existiert

Drei Jobs fallen auf diese ~33K:

1. Arbeitsraum für Compaction. Der Zusammenfassungsprozess selbst braucht Tokens zum Operieren
2. Completion-Buffer. Erlaubt laufenden Aufgaben, fertig zu werden, bevor Compaction auslöst
3. Response-Generierungsraum. Claude braucht Arbeitsgedächtnis zum Denken und Konstruieren von Antworten

Der Buffer ist in Claude Codes Architektur eingebaut. Requests, ihn konfigurierbar zu machen, wurden als Duplikate geschlossen. GitHub Issue #15435 hat danach gefragt. Die Antwort war nein.

Das Output-Tokens-Missverständnis

Viele Entwickler denken, CLAUDE_CODE_MAX_OUTPUT_TOKENS steuert den Compaction-Buffer.

Tut es nicht.

Zwei verschiedene Mechanismen, null Überschneidung:

• Output-Tokens. Begrenzt, wie lang eine einzelne Claude-Antwort laufen kann
• Compaction-Buffer. Reservierter Kontext-Bereich, der Auto-Compaction auslöst

Setze CLAUDE_CODE_MAX_OUTPUT_TOKENS=16000 und du verkleinerst Claudes maximale Antwortlänge. Der Kontext vor Compaction rührt sich nicht. Die 33K Buffer sind fest.

# This limits response length, NOT context buffer
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=16000

Gründe, Output-Tokens zu senken:

• Schnellere Antworten (weniger zu generieren)
• Geringere Kosten pro Antwort
• Prägnanz erzwingen

Nutzbarer Kontext vor Compaction? Immer noch ~167K.

Ein Vorbehalt ist es wert, ihn zu nennen: Obwohl CLAUDE_CODE_MAX_OUTPUT_TOKENS den Compaction-Buffer in Ruhe lässt, kann ein sehr hoher Wert dein effektives Kontextfenster verkleinern. Output-Tokens werden aus demselben Kontext-Pool geschnitzt, also nimmt eine größere Output-Reservierung Platz von History und System-Kontext weg. Der 32K-Standard ist für die meisten Workflows gut ausbalanciert.

Der Reale-Welt-Einfluss

Stell dir eine typische schwere Session vor:

Mit 33K Buffer trifft Compaction bei 167K. Das ist deine Arbeitsdecke, 12K höher als die alte 155K-Grenze.

Wohin geht die Information? In die Zusammenfassung. Genaue Variablennamen, präzise Fehlermeldungen, subtile Entscheidungen aus dem frühen Teil der Session werden alle in einen Recap gepresst, der das Wesentliche trifft und das Detail verliert.

Was du wirklich steuern kannst

1. Den Compaction-Auslöser-Prozentsatz überschreiben

Eine Umgebungsvariable verschiebt tatsächlich, wann Auto-Compaction feuert: CLAUDE_AUTOCOMPACT_PCT_OVERRIDE.

# Trigger compaction at 90% instead of the default ~83.5%
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=90
 
# Trigger earlier at 70% for more aggressive compaction
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70

Werte von 1 bis 100 werden akzeptiert. Die Zahl setzt direkt den Prozentsatz, bei dem Auto-Compaction auslöst. Eine höhere Einstellung gibt mehr nutzbaren Kontext vor Compaction und lässt weniger Raum für den Zusammenfassungsjob. Eine niedrigere Einstellung feuert Compaction früher, behält mehr Arbeitsraum und gibt dir weniger Platz vor dem ersten Treffer.

Das Nächste, was du an einem konfigurierbaren Buffer kriegen kannst. Die Buffer-Größe ändert sich nicht. Es verschiebt den Moment, an dem Compaction relativ zum Gesamtfenster feuert.

2. Extended-Context-Modelle nutzen

Statt mit der 200K-Grenze zu kämpfen, greif zum 1M-Token-Kontextfenster.

Ab März 2026 ist das 1M-Kontextfenster allgemein verfügbar für Opus 4.6 und Sonnet 4.6, ohne Preisaufschlag. Eine 900K-Token-Anfrage kostet pro Token genauso wie eine 9K-Anfrage. Schau in unser 1M-Kontextfenster-Guide für den vollständigen Überblick, was sich geändert hat.

/model sonnet[1m]

Bei 1M Tokens rückt der Compaction-Schwellenwert weit raus. Selbst nach einem proportionalen Buffer wächst der Raum vor Compaction erheblich. Schau in den Model-Selection-Guide für die vollständige Modell-Alias-Referenz.

3. Auto-Compaction deaktivieren (riskant)

// ~/.claude/settings.json
{
  "autoCompact": false
}

Warnung. GitHub Issue #18264 berichtet, dass die Einstellung in manchen Fällen ignoriert wird. Selbst wenn sie hält, riskierst du, gegen harte Kontextgrenzen zu stoßen und Sessions zum Absturz zu bringen.

Dreh das nur um, wenn du bereit bist:

• Kontext manuell mit /context zu überwachen
• /compact auszuführen, bevor du 100% triffst
• Gelegentliche Session-Abstürze zu akzeptieren

4. Manuelles Compaction an strategischen Punkten

Schalte Auto-Compact aus und compactiere nach deinem Zeitplan:

/compact   # Compact when you decide
/clear     # Full reset when starting new major task

Gute Momente zum gezielten Compactieren:

• Nach Abschluss eines größeren Features
• Bevor du eine neue Komponente anfängst
• Wenn der Debugging-Kontext alt wirkt

Vorteil: Du bestimmst, was wann zusammengefasst wird, was die feingranularen Details rund um aktive Arbeit erhält.

5. Im 167K-Limit arbeiten

Akzeptiere, dass schwere Sessions compactieren werden. Richte dich darauf ein:

• CLAUDE.md und Skills schlank halten
• Session-Dateien zum Persistieren von State nutzen
• Komplexe Aufgaben in mehrere Sessions aufteilen

6. Proaktive Backup-Strategie

Der effektivste Zug: Sachen sichern, bevor Compaction ankommt.

Eine Idee, die in der Claude Code-Community Fahrt aufnimmt: Proaktives Clearen bei 50% plus strukturiertes Recovery schlägt verlustbehaftete Auto-Compaction.

Auto-Compaction kondensiert deine Konversation und wirft feine Details weg. Mach stattdessen das:

1. Deine Session kontinuierlich in ein strukturiertes Backup aufzeichnen
2. Kontext manuell bei einem Schwellenwert clearen (z.B. 50%)
3. Aus strukturiertem Backup neu laden statt aus verlustbehafteter Zusammenfassung

Kontext-Fidelität steigt. Das Backup hält genaue Details, die Zusammenfassung wegwirft.

Wie du deinen Betriebsmodus wählst

Die meisten Leute brauchen keine eine magische Einstellung. Sie brauchen den richtigen Modus für die Art von Arbeit, die sie tun.

Die richtige Frage ist nicht "wie schlage ich den Buffer?" Sie lautet: "Wie teuer ist ein verlustbehaftetes Compact für diese Session?"

Drei Praxis-Beispiele

Beispiel 1: Normaler Feature-Build

Du baust ein Feature, änderst eine Handvoll Dateien und die Session überschreitet wahrscheinlich nicht 100K Tokens.

Bester Zug:

• Defaults nutzen
• /context ein- oder zweimal checken
• Nicht über-engineeren

Der Buffer ist hier nicht dein Problem.

Beispiel 2: Debugging-Session mit vielen Sackgassen

Du verbringst 40 Minuten damit, Logs, Traces und fehlgeschlagene Hypothesen zu untersuchen. Du weißt bereits, dass die nächste Phase die Implementierung sein wird.

Bester Zug:

• Nicht auf Auto-Compact warten
• /compact focus on the confirmed root cause, affected files, and fix plan ausführen
• In die Implementierung weitergehen

Das behält die nützliche Diagnose und wirft den Müll weg.

Beispiel 3: High-Detail-Content oder Audit-Session

Stell dir vor, du auditierst einen Security-Flow oder schreibst einen quellenschweren Artikel. Genaue Zitate, Dateipfade und beobachtetes Verhalten sind wichtig.

Bester Zug:

• Strukturiertes Backup oder Notes-Datei führen
• Früher als üblich clearen
• Aus dem genauen Backup statt aus einer compactierten Zusammenfassung wiederherstellen

Hier gewinnt der Backup-Workflow. Das Problem ist nicht die rohe Kapazität. Es ist Informations-Fidelität.

Wann CLAUDE_AUTOCOMPACT_PCT_OVERRIDE geändert werden soll

Diese Variable ist nützlich, aber nur in bestimmten Fällen.

Erhöhe sie wenn:

• die aktuelle Aufgabe kohärent ist und du mehr Raum vor Compaction willst
• du die Auslastung aktiv im Blick behältst
• die Kosten eines zu frühen Compacts höher sind als das Risiko des Wartens

Senke sie wenn:

• die Session unordentlich ist und du früher Zusammenfassungen willst
• du häufigeres Compactieren akzeptierst
• du willst, dass Claude das Working Set enger hält

Lass sie in Ruhe wenn:

• du den Kontext nicht aktiv überwachst
• du keinen klaren Grund hast, den Auslöser zu ändern
• das eigentliche Problem Task-Switching ist, nicht Compaction

Den Auslöser zu ändern ist kein Ersatz für gute Session-Grenzen. Es verschiebt nur, wann derselbe zugrunde liegende Mechanismus feuert.

StatusLine: Der einzige Live-Monitor

StatusLine ist der einzige Mechanismus, der Echtzeit-Kontext-Metriken bekommt. Andere Hooks empfangen keine Token-Counts.

// .claude/settings.json
{
  "statusLine": {
    "type": "command",
    "command": "node .claude/hooks/context-monitor.mjs"
  }
}

Die Statusline empfängt JSON mit context_window.remaining_percentage. Das sind Live-Daten, bereit zum Handeln.

Kritische Berechnung. Das remaining_percentage-Feld zählt den 16,5%-Autocompact-Buffer bereits ein. Für tatsächliches "frei bis Autocompact":

const AUTOCOMPACT_BUFFER_PCT = 16.5;
const freeUntilCompact = Math.max(
  0,
  remaining_percentage - AUTOCOMPACT_BUFFER_PCT,
);

25% übrig bedeutet wirklich 8,5% übrig bis zur Compaction.

Warum Hooks kein /clear injizieren können

Eine technische Mauer, gegen die viele Leute stoßen: Hooks können keine Slash-Befehle injizieren.

Naheliegender Gedanke: Ein Hook entdeckt hohe Kontext-Auslastung und injiziert /clear. Das kann er nicht:

• UserPromptSubmit hat kein updatedPrompt-Feld. Es kann Kontext hinzufügen oder blockieren, aber nie ersetzen
• Slash-Befehle überspringen die Hook-Evaluierung komplett
• Kein Hook feuert "anstatt" User-Input

Echte Wege, um programmatisch zu clearen und wiederherzustellen:

1. Claude Agent SDK. Sende /clear über das SDK
2. Headless CLI-Wrapper. Pippe Befehle an headloses Claude Code
3. Manueller Workflow. Hook warnt dich, du führst /clear aus, SessionStart stellt wieder her

Was bei 100% Kontext passiert

Drück den Kontext ganz bis an die Kante und hier ist, was folgt:

1. Bester Fall. Claudes Antwort wird abgeschnitten
2. Schlimmerer Fall. API gibt einen Fehler zurück, Turn schlägt fehl
3. Schlimmster Fall. Session wird unresponsiv

Die 33K Buffer sind da, um das zu verhindern. Sie sind Schutz, kein Verschwendung.

Kernpunkte

1. Der Buffer sank gerade von 45K auf 33K. Undokumentierte Änderung, etwa 12K mehr nutzbare Tokens
2. Compaction löst jetzt bei ~83,5% Auslastung aus. Das setzt nutzbaren Kontext auf etwa ~167K (hoch von ~155K)
3. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE verschiebt den Auslöser. Werte 1 bis 100 setzen, wann Compaction feuert
4. sonnet[1m] bietet 1M-Token-Kontext. Eine echte Alternative zum Kämpfen mit 200K-Grenzen
5. Output-Tokens und Compaction-Buffer sind getrennt. Nicht durcheinanderbringen
6. autoCompact: false kann funktionieren. Hat auch gemeldete Bugs
7. StatusLine ist der einzige Live-Kontext-Monitor. Andere Hooks sehen keine Token-Counts
8. Hooks können kein /clear injizieren. Geh über das SDK, einen Wrapper oder einen manuellen Workflow
9. Proaktives Clearen plus strukturiertes Recovery schlägt verlustbehaftete Auto-Compaction

Der Buffer ist aus gutem Grund da. Statt gegen ihn zu kämpfen, arbeite damit: behalte State in Session-Dateien, führe schwellenwertbasierte Backups vor der Compaction durch und denke an proaktives Clearen für schwere Sessions.

Die Lösung: Schwellenwertbasierte Backups

Der Buffer ist fest. Wie du mit seiner Annäherung umgehst, nicht.

Schau dir unser schwellenwertbasiertes Backup-System an, ein proaktives Setup, das Kontext durch StatusLine beobachtet und bei 30%, 15% und 5% verbleibend Backups erstellt, bevor Compaction deine Session-History wegwischt.

Verwandte Ressourcen

• Context Recovery Hook - Schwellenwertbasiertes Backup-System
• Context Engineering Guide - Strategische Kontext-Nutzung
• Memory Optimization - Statischen Kontext-Overhead reduzieren
• Claude Code Hooks Guide - Alle 12 Hook-Typen erklärt