Auto-compaction race condition on fast machines - context grows faster than compaction triggers

Resolved 💬 3 comments Opened Dec 26, 2025 by Hippensteel Closed Dec 30, 2025

Summary

Auto-compaction fails to prevent context overflow on fast machines (M4 Pro MacBook Pro) despite working reliably on slower machines (older iMac). The hypothesis is that tool calls complete so quickly on faster hardware that context accumulates between compaction checks, outrunning the safety mechanism.

Environment

  • Claude Code version: 2.0.76
  • Machine: MacBook Pro M4 Pro (14 CPU, 20 GPU cores, 48GB RAM)
  • Model: claude-opus-4-5-20251101
  • OS: macOS Darwin 25.2.0

Evidence

Before/After Machine Comparison

| iMac (older, slower) | MBP M4 Pro (new, fast) |
|---------------------|------------------------|
| Sessions spanning weeks without hitting token limit | Sessions crash within hours |
| Same user, same workflows, same usage patterns | Token limit errors in ~50% of sessions |
| Auto-compaction worked reliably | Auto-compaction triggers too late |

Timing Analysis from Crashed Session

Debug log analysis from session 298e22a6:

204 tool calls completed BEFORE first compaction attempt
Tool breakdown: 150 Bash, 35 Read, 13 TodoWrite, 7 TaskOutput, 7 Glob...

Time between compaction attempts:
  15:47:06 → 15:55:52: 8.8 min (compaction 1→2)
  15:55:52 → 15:57:14: 1.4 min (compaction 2→3, accelerating)
  15:57:14 → 16:00:13: 3.0 min (compaction 3→4, FAILED)
  
Final state: 219,332 tokens > 200,000 limit
Error: "prompt is too long: 219332 tokens > 200000 maximum"
Error: "Error during compaction: Conversation too long"

The Race Condition

  1. On fast hardware, tool calls complete in milliseconds
  2. Compaction check appears to run at message boundaries, not continuously
  3. Between checks, dozens of tool calls can complete, each adding context
  4. By the time the system checks "should I compact?", it's already past the point of no return
  5. Compaction itself requires ~20k tokens of headroom to execute
  6. Once past ~187k tokens, even the compaction request fails

Suggested Fixes

  1. Token-based triggers: Check total tokens added since last compaction, not just message count
  2. Time-based triggers: Add a time-interval compaction check (e.g., every 30 seconds during active tool use)
  3. Larger safety margin: Trigger compaction at 60-65% context instead of 75%
  4. Rate-aware compaction: If tool calls are completing rapidly, trigger compaction more aggressively
  5. Configurable threshold: Allow users to set compaction threshold (per #10691)

Impact

This effectively makes Claude Code unreliable on modern fast hardware for any extended session. Users with faster machines are punished with more crashes, which is counterintuitive.

Debug Data Available

Full debug logs and session JSONLs available if needed for further analysis.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗