Compaction death spiral in Cowork: 6 compactions in 3.5min due to system context consuming 86.5% of window

Status Fixed / completed
Reported on v2.1.38
Maintainer reply None cached
Activity 5 comments · opened Feb 10, 2026 · closed Feb 10, 2026

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

  1. 6 compactions in 3.5 minutes with no cooldown/backoff between them
  2. Compaction #6 failed entirely with "Prompt is too long" — the system context alone exceeded the compaction model's window
  3. Compaction summaries reproduce content verbatim (instructions say "include full code snippets"), making summaries almost as large as originals — defeating the purpose
  4. ~1M tokens wasted on compaction overhead (6 × ~175K input tokens)
  5. 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

  1. 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.
  2. No minimum interval between compactions — allows rapid-fire compaction attempts
  3. 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
  4. 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

  1. Lazy-load MCP tool definitions — only include tools that are actually used or requested, not all tools from all servers
  2. Add compaction cooldown — minimum interval (e.g., 60s) between compaction attempts
  3. Add a circuit breaker — after N failed or rapid compactions, stop and warn the user
  4. Check headroom before compacting — if system context alone exceeds X% of the compaction model's window, skip compaction (it won't help)
  5. Use a larger-context model for compaction when system context is large
  6. 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).

View original on GitHub ↗

5 Comments

github-actions[bot] · 8 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/24179
  2. https://github.com/anthropics/claude-code/issues/24315
  3. https://github.com/anthropics/claude-code/issues/23751

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

sebastienkothe · 8 months ago

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

  1. First report in Cowork mode — none of the referenced issues involve Cowork.
  1. Root cause is MCP tool definitions from cloud integrations — the key finding is that tools from configured cloud.ai integrations (Bitly, Ahrefs, Canva, Gamma, Make, Notion, Clay, Vibe Prospecting, etc.) are loaded into context even when completely irrelevant to the current task. These tool definitions alone consume an estimated ~80K tokens (40% of the context window). This is not mentioned in any of the referenced issues.
  1. Precise context breakdown provided — we identified that system context (CLAUDE.md 28K + MCP tools ~80K + system prompts ~40K + compaction instructions ~25K = 173K/200K) leaves only 13.5% of the window for actual work. The compaction loop is inevitable regardless of task complexity.
  1. New mitigation suggested — lazy-loading MCP tool definitions (only include tools that are used/requested) would free ~40-60K tokens immediately. This is a different fix than the cooldown/circuit-breaker solutions discussed in the other issues.

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.

sebastienkothe · 8 months ago

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.

sebastienkothe · 8 months ago

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.

github-actions[bot] · 7 months ago

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.