Context low warning and /compact failure despite having 86% free context space

I do not believe this issues is fixed yet but I have done a few things to help it.

1 - reset context and client
2 - switched to a different model, entered a few commands, switched back.
3 - I had a couple of large custom MCP servers that were only consuming 10K tokens, but I removed them

Issue is still happening, this is on a new thread.

⎿  Context low · Run /compact to compact & continue

/model

⎿  Set model to opus (claude-opus-4-1-20250805)

confinue

⎿  Context low · Run /compact to compact & continue

/compact

⎿  Error: Error during compaction: Error: Conversation too long. Press esc to go up a few messages and try again.

/model

⎿  Set model to sonnet (claude-sonnet-4-20250514)

continue

⎿  Context low · Run /compact to compact & continue

/compact

⎿  Error: Error during compaction: Error: Conversation too long. Press esc to go up a few messages and try again.

Running into this same issue over the past few hours.

Thanks for the report! Can you guys please paste the output of /doctor here?

It's all the time now (v2.0.2), absolutely broken. Auto compaction doesn’t trigger almost every time, and manual compaction never works, literally never.

<img width="988" height="81" alt="Image" src="https://github.com/user-attachments/assets/8c9dca72-9065-42ae-ae15-17202db0a364" />

<img width="505" height="156" alt="Image" src="https://github.com/user-attachments/assets/7a76b075-e2f7-4f1e-88db-2c3f33b3d3d8" />

Btw, "Press esc twice to go up" is also broken useless — it doesn't allow you to navigate through the actual messages of the model; it only allows you to navigate through user messages. &nbsp;Usually, I only have one message at the very beginning of the conversation. &nbsp;So it's absolutely useless to compact from it.

Even if I have messages further down in the conversation, it doesn't help. I can continue the conversation, but it still doesn't trigger compaction automatically, and if I try to call it manually, it fails every time.

I wanted to add another example of this bug - I'm also seeing the Context low - Run /compact to compact & continue warning even when my context window usage is actually low, but I'm also getting hints to try sonnet[1m] even when I'm already using that exact model

Below is a screenshot that illustrates the problem. You can see according to the /context slash command my session is only at 16% context usage, but I see:

• The Run /compact to continue warning claiming I only have 7% remaining (same as other folks)
• The inline chat hint advising me 7% context left - try /model sonnet[1m] but you can see I'm already the 1M token context variant of Sonnet 4.5 (this is the new part I haven't seen other folks mention yet)

<img width="1107" height="518" alt="Image" src="https://github.com/user-attachments/assets/f0ef1545-a886-46c4-8952-86d5ff9c14d2" />

I am seeing the same error in Claude Code on my Mac using Sonnet 4.5

<img width="1512" height="561" alt="Image" src="https://github.com/user-attachments/assets/a8ec25fd-3ba8-429c-a65d-fdbf87122ed4" />

Just ran into this bug when I noticed the autocompaction happening pretty early. It's a major WTF to see this too:

<img width="732" height="268" alt="Image" src="https://github.com/user-attachments/assets/45e00de6-256a-485e-802a-09023dd39270" />

I first presumed it might be an odd bug with autocompaction because, like, why else would the autocompact buffer be EIGHT HUNDRED AND FORTY FIVE THOUSAND TOKENS LONG, but turning off autocompact does not help.

Okay did someone just push a change

<img width="715" height="555" alt="Image" src="https://github.com/user-attachments/assets/f24b40f7-cb8d-4e52-8dc0-ada912be6a65" />

Nah...

<img width="1152" height="670" alt="Image" src="https://github.com/user-attachments/assets/f9d9cc5c-e8f4-4823-9e66-63324c3b1732" />

> /doctor 

 Diagnostics
 └ Currently running: package-manager (2.0.37)
 └ Package manager: homebrew
 └ Path: /opt/homebrew/bin/claude
 └ Invoked: /opt/homebrew/Caskroom/claude-code/2.0.37/claude
 └ Config install method: global
 └ Auto-updates: Managed by package manager
 └ Search: OK (bundled)

Additional data point - November 16, 2025

Experiencing the same issue with significant MCP tool overhead.

Context breakdown (from /context command):

• claude-sonnet-4-5-20250929 · 157k/200k tokens (78%)
• System prompt: 2.9k tokens (1.4%)
• System tools: 15.4k tokens (7.7%)
• MCP tools: 15.0k tokens (7.5%) ← workspace + workspace-developer MCPs
• Memory files: 5.6k tokens (2.8%)
• Messages: 117.9k tokens (58.9%)
• Free space: 43k (21.7%)

UI Display:

• Shows "Context low (10% remaining)" in red warning bar
• /context command reports 21.7% remaining (43k tokens)
• System warnings in tool results report ~52k tokens remaining (26%)

Configuration:

• 2 MCP servers: workspace (13 tools), workspace-developer (2 tools)
• 3 CLAUDE.md memory files loaded
• Model: claude-sonnet-4-5-20250929

Observation:

The MCP tools overhead (~15k tokens) appears to be confusing the UI gauge calculation. The gauge seems to treat static overhead (MCP tools + system tools + memory files = ~36k tokens) as consuming "message budget" rather than recognizing it as fixed infrastructure cost.

With 43k-52k tokens actually remaining, I can continue productive work, but the UI incorrectly suggests the session is nearly exhausted.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

<img width="692" height="600" alt="Image" src="https://github.com/user-attachments/assets/a0349224-3657-490b-a2ad-12e8050e2a1d" />
<img width="582" height="173" alt="Image" src="https://github.com/user-attachments/assets/ec338a12-5a0b-4837-bab1-6a21ca428642" />
the issue is still occuring for me as well. disabled auto-compact, but now I am constantly prompted for manual compaction, sometimes immediately after compacting.

happend to me when local claude.md was too large.

TL;DR: I'm experiencing this issue too, and it's extremely frustrating. If you have the ability to fix this bug (i.e., engineers at Anthropic, Claude Code developers, QA, leads, etc.—kudos to all of you, by the way!):

Full bug experience review over 4 months :

This is absolutely maddening. No controversy here on my part: I consider Claude Code to be the revolution it rightfully is, as it has enabled me to develop projects I'd been postponing for at least 1.5 decades due to lack of time. Code porting (my specialty) has become trivial, and I've increased my productivity by well over 30x, with most of the time saved in debugging and edge case resolution.

However, I've been affected by this context bug too many times to count, and it has disrupted my workflow for several months now. I'm a very heavy user (spending several thousand dollars per month with Anthropic), working on approximately 10 codebases in parallel, and I ALWAYS use the background agents feature—sometimes parallelizing as many as 50 agents for highly parallelizable development tasks (and it works fine! Well, when agents don't block each other trying to build the same project simultaneously, and when I don't encounter the context issue we're discussing here).
Here's my latest example with 4 background agents: The context limits are completely exceeded at 191% context size, or 383K tokens! Most of the context is consumed by "Messages" (see screenshot).

<img width="1800" height="1169" alt="Image" src="https://github.com/user-attachments/assets/1db1c3aa-4f16-4f87-89c9-4bc7e5315a4c" />

And I didn't even try hard to trigger the error. In my case, it ALWAYS occurs when the main agent (the one I'm actively prompting) decides to read the outputs of active background tasks. When those tasks are new, everything works fine. However, when they begin accumulating millions of tokens each, their output becomes massive, and all of this text being read and added to my main context window simply causes it to explode.

I found a workaround that SOMETIMES helps, because the main agent LOVES to parse and read the output of its background agents. After finishing my initial multi-agent work-phase prompt, I specifically instruct the main agent not to directly access agent outputs. Instead, I ask it to use tail -n 200 each time it wants to check for completion.
This doesn't eliminate the fact that token usage in the main agent is higher during parallel agent work, but at least when the main agent follows instructions, it works reasonably well. However, after a /compact operation, the main agent often forgets it shouldn't open the full subagent output and ends up crashing the context anyway.

This should be in the "Critical" bug fixes section. In thousands of agent-hours of intensive development with Claude Code to date, I have not found any other issue of this magnitude.

This would be a dealbreaker if Claude weren't so exceptional... I would greatly appreciate this bug being fixed. The fix is quite straightforward to implement (at least in my specific case).

Thanks for reading.

PROPER BUG REVIEW

Bug Report: Context Limit Exceeded When Main Agent Reads Background Task Outputs
Severity: Critical
Summary:
When the main agent reads outputs from active background tasks, the context window frequently exceeds its limit (observed at 191% capacity / 383K tokens), causing workflow disruption.
Environment: macos Tahoe ; macbook pro M4 pro 48 Gb 1 Tb.

Heavy usage pattern: ~10 concurrent codebases, frequent use of background agents feature
Common scenario: 4-50 parallel background agents

Reproduction Steps:

Initialize multiple background agents for parallel development tasks
Allow background agents to accumulate substantial output over time
Main agent attempts to read full outputs from these background tasks
Context window exceeds limit

Root Cause:
The main agent frequently parses complete background agent outputs, loading millions of tokens into the main context window. This is particularly problematic as background tasks mature and generate extensive logs.

Current Workaround:
Explicitly instructing the main agent to use tail -n 200 instead of reading full outputs reduces token consumption. However, this workaround is unreliable—the constraint is often forgotten after /compact operations, resulting in context overflow.

Impact:
This issue consistently disrupts multi-agent workflows and is the most significant bug encountered across thousands of agent-hours of development.
Suggested Fix:
Implement hard limits or automatic truncation on background agent output reading to prevent context overflow, regardless of agent instructions.

This is SO old and SOOO annoying bug that still persist even in latest versions:

<img width="1528" height="498" alt="Image" src="https://github.com/user-attachments/assets/c0853015-1271-475e-bb4e-a23e8320f474" />

When /compact itself dies with "Conversation too long," the session is stuck with no in-app recovery — switching models doesn't help, as the thread shows. An offline pruner gets you out: cozempic rewrites the session JSONL (old tool results stubbed, base64 images and superseded reads removed) so you can reopen it with headroom and skip compaction entirely. uvx cozempic, then cozempic treat <session-id> --execute (it writes a backup first). It's open source; cozempic diagnose <session-id> will also show whether the displayed 86%-free is matched by the measured token count.