Compaction death spiral in Cowork: 6 compactions in 3.5min due to system context consuming 86.5% of window
Bug Description
When using Cowork on a project with a large CLAUDE.md (~32KB) and multiple MCP servers configured, the system context alone consumes ~173K out of 200K tokens (86.5%), leaving only ~27K tokens for actual work. This causes a rapid compaction loop — 6 compactions in 3.5 minutes — even on a brand new task.
The task was straightforward: read theme files and create a markdown document. No screenshots, no heavy payloads — just file reads and a file write.
Environment
- Claude Code version: 2.1.38
- OS: macOS 15.6.1 (arm64)
- Mode: Cowork
- Model: Opus (main) + Haiku (subagents/compaction)
System context breakdown
| Component | Estimated tokens | % of ~200K window |
|-----------|-----------------|-------------------|
| CLAUDE.md (project instructions) | ~28,000 | 14% |
| MCP tool definitions (Chrome DevTools, Firebase, Marionette, Bitly, Ahrefs, Canva, etc.) | ~80,000 | 40% |
| System prompts (Claude Code internals) | ~40,000 | 20% |
| Compaction instructions | ~25,000 | 12.5% |
| Total system context | ~173,000 | 86.5% |
| Remaining for actual conversation | ~27,000 | 13.5% |
Reproduction timeline
Session f897d038 on February 10, 2026:
00:01:13 [USER] Prompt: extract design system, create CHARTE_GRAPHIQUE.md
00:01:17 [OPUS] Launches Haiku subagent to explore Flutter theme files
00:01:28 [HAIKU] 6 parallel Glob calls → cache_creation: 173,573 tokens (system context)
00:01:30 [COMPACT] #1 (276f76) - OK - only Glob results in context
00:01:45 [COMPACT] #2 (c141e8) - OK - file reads started accumulating
00:02:21 [COMPACT] #3 (f8f79b) - OK - more search results
00:02:56 [COMPACT] #4 (2a70bc) - OK - full file contents in context
00:04:30 [HAIKU] Subagent completes (194K total tokens, 15 tool calls)
00:04:43 [COMPACT] #5 (52ccd8) - OK - CSS files discovered
00:04:59 [COMPACT] #6 (93c559) - FAILED: "Prompt is too long" (0 output tokens)
00:07:31 [OPUS] Writes output file successfully
00:08:46 [END] Session complete
Key observation: The compaction subagents (Haiku) show cache_read_input_tokens: 173,530 consistently — this is the system context being loaded each time. With a ~200K window and 173K consumed by system context, reading just 4 theme files (~4-6K tokens) is enough to trigger compaction.
Problems observed
- 6 compactions in 3.5 minutes with no cooldown/backoff between them
- Compaction #6 failed entirely with "Prompt is too long" — the system context alone exceeded the compaction model's window
- Compaction summaries reproduce content verbatim (instructions say "include full code snippets"), making summaries almost as large as originals — defeating the purpose
- ~1M tokens wasted on compaction overhead (6 × ~175K input tokens)
- No awareness of available headroom — the system doesn't seem to account for how much of the context window is consumed by system instructions before deciding whether compaction will help
Root causes
- System context is too large relative to the model window — 86.5% leaves no room. With Haiku's ~200K window, even a trivial task triggers compaction immediately.
- No minimum interval between compactions — allows rapid-fire compaction attempts
- No circuit breaker — when compaction #6 fails with "Prompt is too long", the system should recognize that the problem is structural (system context too large) and stop trying
- MCP tool definitions are loaded eagerly — tools from all configured MCP servers (Chrome DevTools, Firebase, Marionette, Canva, Bitly, Ahrefs, Gamma, Make, Notion, Clay, Vibe Prospecting) are included in context even when irrelevant to the current task
Suggested mitigations
- Lazy-load MCP tool definitions — only include tools that are actually used or requested, not all tools from all servers
- Add compaction cooldown — minimum interval (e.g., 60s) between compaction attempts
- Add a circuit breaker — after N failed or rapid compactions, stop and warn the user
- Check headroom before compacting — if system context alone exceeds X% of the compaction model's window, skip compaction (it won't help)
- Use a larger-context model for compaction when system context is large
- Produce terser summaries — reference file paths instead of reproducing full code snippets
Related issues
- #24179 — Compaction death spiral (211 compactions, zero progress)
- #22758 — Auto-compact infinite retry loop (695M tokens overnight)
- #20696 — Compaction fails/deadlocks (labeled
oncall) - #24615 — "No room in context" with 17% usage
- #15426 — Binary files read after compaction, filling context
This is the first report specifically about Cowork triggering the compaction loop due to the combined system context size (large CLAUDE.md + many MCP servers).
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of the referenced issues. Here's why:
#24179 (211 compactions): Root cause is large CLAUDE.md + hundreds of untracked files in git status. Different trigger.
#24315 (9 compactions on ESP32): Single-file project on Windows, no MCP servers involved. Different scenario.
#23751 (compaction fails at 48%): About premature failure, not a compaction loop. Different symptom.
What makes this issue unique
The symptom (compaction loop) is shared with #24179, but the root cause (eager MCP tool loading in Cowork consuming 40% of context) and the suggested fix (lazy-load MCP definitions) are distinct.
Update: Claude Desktop (not CLI), disabling MCP integrations did NOT help
Correction: This issue occurs on Claude Desktop (Cowork mode), not Claude Code CLI. The Cowork project directory (
~/Documents/Cowork/) has a small CLAUDE.md (~9KB), not the 32KB one initially referenced.What we tried
Disconnected all unused cloud.ai MCP integrations (Bitly, Ahrefs, Canva, Gamma, Make, Notion, Clay, Vibe Prospecting) from claude.ai Settings → Integrations, keeping only Chrome DevTools.
Result: no change. Compaction triggered immediately on a fresh new Cowork session, even with most integrations disconnected.
Revised assessment
The initial hypothesis (MCP tool definitions consuming ~80K tokens) was incorrect or insufficient. The compaction loop occurs even with minimal MCP integrations, on a fresh task, with a small CLAUDE.md (~9KB).
This suggests the issue is deeper in the compaction mechanism itself — possibly related to how Claude Desktop/Cowork initializes sessions or how the compaction threshold is calculated, rather than raw context consumption from MCP tools.
This aligns more closely with #20696 (compaction fails/deadlocks on Claude Desktop) and #24179 (compaction death spiral) than initially thought.
Closing as duplicate. The initial MCP-specific hypothesis was incorrect — disabling integrations did not resolve the issue. This is the same compaction loop bug reported in #24179 and #20696. Upvoting those instead.
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.