[Bug] Context limit reached with 32k tokens free space and auto-compact disabled

hey folks, awesome work on everything you’ve been shipping lately! 🙌 i’m seeing the same issue mentioned above, and it pops up sporadically and tends to interrupt the workflow. just wondering if it’s been flagged internally yet or if there’s any known workaround?

---

Context limit reached · /compact or /clear to continue:

⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Compact buffer: 3.0k tokens (1.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Free space: 102k (50.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀

Context low (3% remaining) · Run /compact to compact & continue

⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Compact buffer: 3.0k tokens (1.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀ ⛶ Free space: 87k (43.3%)

Context low (0% remaining) · Run /compact to compact & continue

⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Compact buffer: 3.0k tokens (1.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Free space: 100k (49.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀

Context low (0% remaining) · Run /compact to compact & continue

⛁ ⛁ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Compact buffer: 3.0k tokens (1.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Free space: 52k (25.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀

Context low (0% remaining) · Run /compact to compact & continue

⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Compact buffer: 3.0k tokens (1.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Free space: 108k (53.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀

Context low (0% remaining) · Run /compact to compact & continue

and there's also this (don't know if they're related or not):

---

ERROR:

⎿  API Error: Claude's response exceeded the 32000 output token maximum. To configure this behavior, set the CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable.
⎿  Context limit reached · /compact or /clear to continue

---

⏺ Read(docs/folder-name/filename.md)
⎿  Error: File content (30965 tokens) exceeds maximum allowed tokens (25000). Please use offset and limit parameters to read specific portions of the file, or use the GrepTool to search for specific content.

---

thanks in advance. 🙏

Got the same problem. Kind of annoy because I was forced to /compact when I can just push 1 small step to complete the task
<img width="775" height="410" alt="Image" src="https://github.com/user-attachments/assets/b74e25f5-e0e7-4934-ae82-c218345fc19a" />

Confirming this bug - additional data point

Experiencing the same issue. Adding my specifics to help narrow down the root cause.

My conditions

| Attribute | My Case | Original Report |
|-----------|---------|-----------------|
| /context reported | 172k/200k (86% used, 14% free) | 165k/200k (82% used, 16% free) |
| Status bar showed | "0% remaining" | (not specified) |
| Blocked? | Yes - "Context limit reached · /compact or /clear to continue" | Yes - same message |
| Platform | macOS (darwin) | macOS (darwin) |
| Just compacted? | Yes - compacted minutes before hitting this | Unknown |

Key detail: Post-compaction timing

The conversation had just been compacted shortly before hitting this block. Within a few minutes of compaction, the context limit was triggered despite /context confirming significant free space remained.

This suggests the bug may be related to:

1. A stale/cached context calculation not updating after compaction
2. A race condition between compaction completing and context limit checks
3. The status bar and the blocking logic using different (incorrect) token counts than /context

Conversation ID

fa569f8a-4732-48b6-bdf1-956ed1ebe670

(In case this helps with any server-side log correlation)

Additional observation

The status bar explicitly showed "0% remaining" while /context showed 14% remaining - a 14 percentage point discrepancy. This matches the pattern in related issues #9517, #11335, and #17183 where the status bar calculation diverges from the actual context state, but in this case (and the original report) it's not just a display bug - it's actually blocking the conversation.

Follow-up: Full environment details

Removing the conversation ID from my previous comment (unlikely to help with client-side debugging). Here's the complete environment info:

Environment

| Component | Value |
|-----------|-------|
| Claude Code version | 2.1.9 |
| Model | claude-opus-4-5-20251101 (Opus) |
| Extended thinking | Always enabled (alwaysThinkingEnabled: true) |
| Auto-compact | Disabled (same as original reporter) |
| Platform | macOS 15.7.3 (Sequoia), Darwin 24.6.0 |
| Terminal | VS Code integrated terminal 1.108.1 |
| Shell | zsh |
| Permission mode | bypassPermissions |
| IDE auto-connect | Enabled |

Matching conditions with original report

| Condition | Original (#18159) | My case |
|-----------|-------------------|---------|
| Auto-compact disabled | ✅ Yes | ✅ Yes |
| Platform | darwin | darwin |
| Model | opus-4-5 | opus-4-5 |
| Blocked despite free space | ✅ Yes (16% free) | ✅ Yes (14% free) |
| Version | 2.1.7 | 2.1.9 |

Key difference

My case occurred immediately after a manual /compact - within minutes of compacting, the context limit was triggered. This suggests the bug may be related to post-compaction state not being properly reflected in the context limit check.

Context breakdown at time of bug

/context showed: 172k/200k tokens (86% used)
Status bar showed: "0% remaining"
Result: Blocked with "Context limit reached"

Relevant config

• No MCP servers configured for this project
• No active plugins (marketplace installed but plugins object empty)
• Extended thinking always on (may increase per-turn token usage)

Hypothesis

The context limit enforcement appears to be checking a stale or cumulative token count rather than actual current context window usage. This matches the finding in #17183 where total_input_tokens and total_output_tokens are cumulative session totals that never reset after compact.

The blocking logic may be using these cumulative values while /context correctly shows actual current usage.

same issue

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?

60k tokens locked

What Should Happen?

Environment:

• Model: claude-opus-4-5-20251101
• Context window: 200k tokens
• Platform: Claude Code (terminal)

Description:
At 0% context in console with automatic compactation disabled, Claude Code shows "Context limit reached" and suggests /compact or /clear to continue.

However, the /context Usage panel shows 63k tokens free (31.3% of the 200k window).

Expected behavior:
With 31.3% free context, the session should not be blocked.

Actual behavior:
Session is blocked with "bypass permissions on" state, unable to continue despite available context space.

Breakdown shown:

• Messages: 93.5k tokens (46.8%)
• System tools: 16.7k tokens (8.3%)
• Memory files: 12.7k tokens (6.3%)
• MCP tools: 7.6k tokens (3.8%)
• System prompt: 3.9k tokens (1.9%)
• Compact buffer: 3.0k tokens (1.5%)
• Skills: 86 tokens (0.0%)
• Free space: 63k (31.3%)

Also, 200k tokens context window is INSUFFICIENT for MAX x20 users.

Error Messages/Logs

Steps to Reproduce

Just chat until you find 60k tokens are locked

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.12 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

same exact issue for !

Same for me. 82% is the number it consistenly gets to before forcing a compact. /context confirms that 18% is left so the measurement is correct.

Still hitting this on v2.1.25 today (Jan 29).

Got blocked at 127k/200k tokens - that's only 63% usage with 73k still free. Happened multiple times today. Running Opus 4.5 on macOS with auto-compact disabled.

The v2.1.21 seemed to fix this issue for a while, but now it is happening again and even more inconsistently. I also am appending an additional system prompt for additional context around use case.

And just to reiterate what others have said - auto-compact is not usable as it makes claude memory unstable.

Same here, limit reached:

❯ /context
⎿ Context Usage
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ claude-sonnet-4-5-20250929 · 83k/200k tokens (41%)
⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ Estimated usage by category
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ System prompt: 2.8k tokens (1.4%)
⛁ ⛁ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System tools: 16.6k tokens (8.3%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ MCP tools: 293 tokens (0.1%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Skills: 61 tokens (0.0%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Messages: 62.1k tokens (31.0%)
⛶ ⛶ ⛶ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛶ Free space: 85k (42.6%)
⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ Autocompact buffer: 33.0k tokens (16.5%)

<img width="553" height="42" alt="Image" src="https://github.com/user-attachments/assets/9233a1eb-1315-41fa-9e03-ee7ac6a028e0" />

Let me tell you about a scenario I encountered, and see if you've experienced similar problems: I was using Playwright for UI automation, and it had a screenshot tool. After taking a screenshot, it returned the image content to the context. Because the image content was large, the context exceeded the limit and couldn't even be automatically compressed, even though I thought I had plenty of free space at the time.

I get the same error. but it seems to be triggered more quickly and often if I paste screenshots into CC

This is not a minor issue. It's become a real constant productivity killer

The "Conversation too long" failure on /compact is the nasty part here — when the built-in compaction won't run, there's no in-app way out. Pruning the session file offline sidesteps that: cozempic treat <session-id> --execute (via uvx cozempic) stubs old tool outputs and strips superseded reads, so the next resume has real free space and /compact isn't even needed. We wrote it open source after hitting this exact lockout. Run cozempic diagnose <session-id> first if you want to see where the tokens actually went.