[Bug] Context limit reached without automatic compaction triggering

147k tokens...
Context limit reached · /compact or /clear to continue

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/30396
2. https://github.com/anthropics/claude-code/issues/27560
3. https://github.com/anthropics/claude-code/issues/24976

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

I really don’t know how many more times this problem has to happen.

+1
## Bug Description

Auto-compaction does not trigger before reaching the context limit when using
the 1M token context window. The session abruptly stops with "Context limit
reached" instead of auto-compacting to free up space.

## Environment

• Claude Code on Windows 11
• 64GB RAM
• Model: claude-haiku-4-5-20251001 (also observed with other models)
• Date: March 2026

## Steps to Reproduce

1. Start a Claude Code session with a large codebase
2. Perform extensive work (multiple file reads, edits, tool calls)
3. Continue working until context fills up

## Expected Behavior

Auto-compaction should trigger at some threshold (e.g., 80-90% of context
limit) to free up context space and allow the session to continue without
interruption. This behavior previously worked when the context window was
smaller (pre-1M expansion).

## Actual Behavior

No auto-compaction occurs. The session hits the context limit and stops
abruptly. Observed on multiple occasions:

• Session 1: Context limit reached at ~500,000-590,000 tokens (per status

bar) without auto-compaction

• Session 2: Context limit reached at ~236,000 tokens without

auto-compaction

In both cases, manual /compact was required. Prior to the 1M token
context window expansion, auto-compaction would trigger automatically.

## Impact

• Loss of work momentum during complex tasks
• Risk of losing unsaved context/progress
• Forces users to manually monitor context usage and run /compact

proactively

• Particularly impactful during long collaborative sessions (e.g.,

interactive walkthroughs) where pausing to compact is disruptive

## Workaround

Manually run /compact before reaching the limit. However, this requires
constant monitoring of the context percentage in the status bar.

Hey...

<img width="1260" height="592" alt="Image" src="https://github.com/user-attachments/assets/f245d7a1-4df7-4246-9440-61e2a1782781" />

This isn't the same issue is it?

There's no way I have 1189K tokens of messages in this session, it's ~460K tokens worth of messages for this session - I compact the session regularly, have even cleared it a few times. This appears to be happening during a service outage. What the heck is going on? It's not letting me compact this even.

<img width="2400" height="1050" alt="Image" src="https://github.com/user-attachments/assets/df2c8737-af52-4356-b3d7-b500271fb080" />

Still a issue 04/03/26 context limit reached at < 450,000 while should be 1M

Any update?

Happened again today, 4/14/26 8:36am EST, while Claude Code was reporting context of 294,544 tokens (not anywhere close to 1M)
Claude Code version 2.1.204 (per Claude Code, this is the latest version as of this moment )

claude update

Current version: 2.1.104
Checking for updates to latest version...
Claude Code is up to date (2.1.104)

Happened again today

<img width="1355" height="182" alt="Image" src="https://github.com/user-attachments/assets/1ee1145b-5169-40cb-b757-7b94ca72e781" />

I might have figured it out.

It generates <system-notification> lines that contain code changes.

I reformatted my repo tree and then sent a message; I had a debugger attached and it tried to send an enormous change set as a <system-notification> user message of changes relative to files the agent had previously touched. I aborted the process and restarted it, no change set - could pick back up where I left off. The downside is that I am on an older version, but... smoking gun?

I am currently pinned at v2.1.80 and have some custom patches applied to avoid this issue. That is some insane stuff. 🤯
Silent hidden system-notification messages destroying context and possibly some misreads of current compaction-window session history depth after restarts on newer versions causing inability to send messages. @kimmeyh I recommend editing your jsonl file for that session and inserting a custom variant of a compaction line to "recover" it into a new compaction window. Can even instruct a new Claude session to act as a "neurosurgeon" on that session's jsonl. That will at least let you continue.

Not sure if fixed in 2.1.113, but auto-compact has happened twice since start of 04/18/26. Noting that both time it occurred Tokens was being reported at < 500K. However, prefer auto-compaction early or token count being incorrect than complete failure to do auto-compaction.
Failed to auto-compact today at 513851 tokens, version 2.1.113
Image
Upgraded to 2.1.114 04/20/26

Not sure if fixed in 2.1.113, but auto-compact has happened twice since start of 04/18/26. Noting that both time it occurred Tokens was being reported at < 500K. However, prefer auto-compaction early or token count being incorrect than complete failure to do auto-compaction.
Failed to auto-compact today at 513851 tokens, version 2.1.113
Image
Upgraded to 2.1.114 04/20/26

Adding a data point and a critical detail not yet captured in this thread.

The issue is reproducible on Windows 10 / Claude Code 2.1.113 / Max (5x) plan in fresh sessions with heavy development tool use. The session usage page (claude.ai/settings/usage) showed only ~15% of the session allocation consumed when the limit error occurred — the failure is happening well before the context window is full.

Most importantly — the financial impact of the stuck state: When auto-compact fails to fire and the limit is hit, manual /compact also fails with the same error. On the Max plan, the only escape is:

1. Enable "extra usage" (paid overage) — this charges the account balance
2. Run /compact with extra usage active
3. Disable extra usage and continue

Users are being forced to pay real money just to recover from a bug in the compaction system. None of the existing comments mention this. It is a significant consequence that should be factored into prioritisation.

Auto-compact works correctly on Linux (same account) and macOS (different account) with the same Claude Code version and configuration, pointing to a platform-specific regression on Windows.

See also: #51207

When CC's auto-compact doesn't fire and you hit the wall with no warning, having a second, independent trigger helps. cozempic's guard daemon watches session size and auto-prunes at thresholds you configure (defaults 25/55/80% of the window), so you're not relying solely on CC's compaction firing. For a session that's already stuck, cozempic treat <session-id> --execute reclaims space directly (writing a backup first). Open source, uvx cozempic to start. Won't fix why auto-compact isn't triggering, but it keeps a stuck session moving.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.