[Bug] Context limit reached at 21% usage after 11-minute extended thinking — /compact also fails

Environment

• Claude Code: v2.1.41
• Model: Opus 4.6 (Claude Max)
• OS: macOS Darwin 25.3.0
• Session ID: 4721a313-bd20-426e-b9c5-24ebcb598a52
• MCP Servers: 15 configured (Cloudflare suite + Playwright + Context7 + Claude-in-Chrome)

Bug Description

"Context limit reached" triggered at only 21% context usage (42k/200k tokens). Both /compact and continue failed, leaving the session completely stuck with no recovery path except /clear.

The /context command confirms massive free space that should be available:

System prompt:      5.3k tokens (2.6%)
System tools:      15.3k tokens (7.7%)
Memory files:       8.4k tokens (4.2%)
Skills:             1.4k tokens (0.7%)
Messages:          11.6k tokens (5.8%)
Free space:          125k (62.5%)
Autocompact buffer:  33k (16.5%)
Total:             42k/200k (21%)

125k free space — yet "context limit reached."

Steps to Reproduce

1. Start a session with ~15 MCP servers configured (Cloudflare MCP servers using npx mcp-remote)
2. Ask a complex question involving MCP tool research
3. Claude launches a Task subagent that uses 69.7k tokens across 57 tool calls (~10 minutes)
4. Ask follow-up questions that include image attachments (screenshots)
5. Claude enters extended thinking — "Cogitated for 11m 27s"
6. After the long cogitation completes → "Context limit reached · /compact or /clear to continue"

What Happens

1. Status bar shows 21% — nowhere near full
2. /context confirms only 42k/200k used with 125k free
3. continue → blocked by same "Context limit reached" gate
4. /compact → Error: Error during compaction: Error: Conversation too long. Press esc twice to go up a few messages and try again.
5. No recovery path — forced to /clear and lose all session context

Key Observations

• Images were submitted during the session — this aligns with #25332 and #23989 which identify image input as a trigger
• 11-minute extended thinking — the extremely long cogitation may be the actual trigger or contributing factor. Possible that output tokens from extended thinking are not reflected in the /context accounting but push some internal limit
• 15 MCP servers configured — all deferred via Tool Search (only 15.3k tokens for system tools), so MCP overhead is well-managed. Unlikely to be the cause
• Task subagent returned a large result — 69.7k tokens were used in the subagent; the returned summary may have been large
• Autocompact never fired — went straight from working to deadlocked despite 33k autocompact buffer being reserved

Expected Behavior

1. At 21% usage, the session should continue normally
2. If context is genuinely exhausted (perhaps due to unaccounted extended thinking tokens), autocompact should fire automatically
3. /compact should succeed as a manual fallback
4. The /context display should accurately reflect ALL token usage, including any extended thinking overhead that counts against the context window

Hypothesis

The extended thinking output (11+ minutes of chain-of-thought) may generate a very large number of tokens that:

• Are not displayed in the /context accounting
• Still count against some internal limit
• Cause a misleading "context limit reached" error when the actual issue is output token exhaustion or an API-level limit

Screenshots

Session showing /context output with 21% usage alongside "Context limit reached" error — available upon request.

Related Issues

• #25332 — Same model (Opus 4.6), same symptom, identifies image input as trigger
• #23989 — Premature context limit at ~51% with image + mid-processing timing
• #25602 — Context limit at 70%+ free context
• #25011 — Context limit without autocompact triggering