[BUG] Compaction death spiral - 211 compactions consuming all tokens with zero progress
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Description
A conversation entered an infinite compaction loop, triggering 211 compactions in a single session. 95% of these were rapid-fire (≤10 lines apart),
making zero meaningful progress while consuming my entire token quota.
What Happened
The session had 3 phases:
┌─────────────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────┐
│ Phase │ Lines │ Description │
├─────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────┤
│ Normal work │ 0–308 │ Running tools, editing files, building Xcode project — everything fine │
├─────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────┤
│ Work with interruptions │ 308–996 │ 149 tool calls completed despite occasional compaction │
├─────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────┤
│ Death spiral │ 1,053–2,534 │ ~200 compactions in a loop, no meaningful work done │
└─────────────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────┘
In the death spiral, the model repeated this cycle endlessly:
compact → read summary → attempt to read a file → context full → compact → read summary → attempt same file → context full → ...
The model was trying to fix a Python script (convert_to_ios.py), but every time it read the file, the context window filled up and triggered
another compaction. It never had enough remaining context to actually edit the file.
Root Cause
The system context consumed nearly the entire context window, leaving almost no room for actual work:
- Massive git status: Hundreds of untracked files (generated PNG images with long paths) — the git status alone was enormous
- Large CLAUDE.md files: Project had detailed specification docs loaded into system context
- MEMORY.md: Additional persistent memory content
- Compaction summary itself: Each summary was substantial, further reducing available space
After compaction, the system prompt + summary + git status already approached the context limit. Reading even one file pushed it over, triggering
re-compaction immediately.
Evidence
- Transcript file: 17MB, 2,670 lines
- 211 compaction events detected in the transcript
- 201 (95%) were rapid-fire with ≤10 lines between them
- The spiral consumed 1,599 lines of transcript with no useful output
- User had to manually interrupt after noticing the session was stuck
Expected Behavior
- Circuit breaker: After N consecutive compactions (e.g., 3–5) without meaningful tool calls between them, the system should stop and notify the
user instead of continuing the loop
- User visibility: Show a warning when compaction frequency is abnormally high (e.g., "Context is too constrained to make progress")
- Smart context management: When system context (git status, CLAUDE.md, etc.) consumes most of the window, the system should detect this and
either trim the git status or warn the user
- Token protection: Set a maximum compaction count per session to prevent unbounded token consumption
Impact
- Entire token quota exhausted with zero productive output
- User had no clear indication of what was happening — only saw repeated "compacting" status
- No self-recovery — the model could not detect or escape the loop
Environment
- Claude Code version: 2.1.37
- Model: claude-opus-4-6
- Platform: macOS (Darwin 25.2.0, ARM64)
- Session ID: 45e02365-ab02-46dd-9a15-bfe6cff9fd88
What Should Happen?
When the system detects that compaction is occurring repeatedly without meaningful progress (e.g., 3–5 consecutive compactions with no successful
tool calls between them), it should:
- Stop the loop automatically and display a clear error message to the user, such as: "Context is too constrained to make progress. Consider
starting a new session or reducing system context (e.g., commit/gitignore untracked files)."
- Not consume additional tokens on futile compaction cycles.
Currently, there is no circuit breaker — my session ran 211 compactions in a row, consuming my entire token quota with zero useful output and no
user-facing warning.
Error Messages/Logs
Steps to Reproduce
- Open a project with a large system context:
- Large CLAUDE.md file (detailed project specs)
- Large MEMORY.md file
- Hundreds of untracked files in git (e.g., generated PNG images), causing git status output to be very large
- Start a long, multi-step coding task that involves reading and editing files (in my case: fixing bugs in a Python script + building an Xcode
project)
- Continue working in the same session as context accumulates
- Once the first compaction triggers, the system context (git status + CLAUDE.md + MEMORY.md + compaction summary) fills nearly the entire context
window
- The model attempts to read a file, context overflows, triggers another compaction — entering an infinite loop
Key condition: The system context alone must be large enough that after compaction, there is insufficient room to read even one file without triggering re-compaction.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.34
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
12 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I've also been experiencing this since last night. my Claude Code would automatically begin to compact a few prompts into the interaction, and then compact would fail either automatically or manually.
Related scenario: 10+ parallel subagents completing simultaneously filled the context window before compaction could run. Every agent result showed "Context limit reached" and
/compactwas unavailable. The session was unrecoverable — only/clearworked.Seems like a common root cause across these context limit issues: no backpressure on incoming async results (subagent completions, background task output) and no ability to compact when context is already at the limit.
Hit this exact same problem — compaction spiraling out of control, eating all my tokens with zero progress. The root cause in my case was progress tick bloat: a single session had thousands of progress entries averaging ~3MB each while the actual conversation was under 1MB.
What solved it for me was Cozempic — it runs a background guard daemon that continuously prunes the bloat (progress ticks, stale reads, metadata) before compaction ever triggers.
cozempic initauto-wires aSessionStarthook that spawns the guard daemon in the background on every session. It does tiered pruning — gentle trim at 60% threshold, full prune at the hard limit. Since running it, I haven't hit a single compaction spiral.You can also diagnose an existing session to see exactly where the bloat is:
On a 29MB session I saw 5.5% was just progress ticks alone.
progress-collapsein the gentle tier would have prevented the spiral entirely.Constant issues with this exhaustion. Not a usable tool at this point and upset i paid for a year. The running into rate and not having a buffer to write what is happening is almost criminal. It's like you have to anticipate running out of tokens in order to save your work. Support via the chat bot, support email, billing email all 100% unresponsive. Horrible customer service.
Reporting platform: Windows 11 Pro Desktop app (latest version), Max plan
Configuration:
Behavior:
Within 2–3 minutes of starting a new session, the app enters a continuous compaction loop. Compaction fires repeatedly with no meaningful work occurring between cycles. No error is displayed — the app simply loops silently. This occurs consistently across new sessions, including after full system restarts.
Why this matters beyond existing reports:
My normal paid Max plan workflow requires both extended thinking and MCP servers simultaneously. This is not an edge case — it is the intended use of the Max plan. The compaction spiral makes the app entirely unusable in its default configuration for this workflow. There is no viable workaround: disabling extended thinking degrades the core value of the Max plan, and switching MCPs to "On demand" only delays the spiral since all MCPs are required and will be loaded regardless within the first few exchanges.
What is needed:
A circuit breaker that stops the loop and surfaces a clear error rather than cycling silently, and accurate token accounting that includes extended thinking tokens in the visible context meter so users and the system can make informed decisions before compaction is triggered.
Additional note:
The in-app bug reporter on Windows Desktop consistently fails to attach logs, displaying a visible failure message on screen. This further limits the ability of Windows users to report issues through normal channels, and may explain why this thread has so few Windows-specific reports despite the issue being reproducible there.
hit this in a long session running 5 parallel agents. the compaction loop seems to trigger when the context is already near the limit and the summary itself pushes it back over, causing another compaction. our workaround was breaking long tasks into smaller sessions with explicit state handoff - write the current state to a file, start a fresh session, read the file back. not ideal but it avoids the spiral. the real fix would be for compaction to have a circuit breaker that stops after N attempts and forces a hard context reset instead of retrying.
for the state handoff pattern we use between sessions, here's the tool execution layer that handles intermediate state: https://github.com/m13v/fazm/blob/main/Desktop/Sources/Providers/ChatToolExecutor.swift - and our background agent scheduler that manages session lifetimes: https://github.com/m13v/tmux-background-agents/blob/main/SKILL.md
The compaction death spiral happens when the session is so bloated that compaction can't shrink it enough — context immediately grows back to the threshold and triggers another compaction. 211 compactions burning all your tokens.
Cozempic v1.4.1 breaks this cycle by proactively pruning before the threshold is ever reached. The guard daemon monitors token usage and fires strategies (gentle at 45%, hard at 75%) well before CC's auto-compact triggers. The new
compact-summary-collapseremoves 85-95% of pre-compaction content in one pass.pip install cozempic && cozempic initWould be interested to hear if this eliminates the spiral for anyone here.
This was fixed in v2.1.89 — Auto-compaction now stops with a clear error after three rapid context-refill cycles instead of looping indefinitely and consuming tokens with no progress. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.
Happened last night in 2.1.112
See #51088
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.