Compaction fails with 'Conversation too long' at 48% context usage (Opus 4.6)
Status Closed — duplicate
Maintainer reply ✓ Yes — claude[bot]
Workaround ✓ Mentioned in description ↑
Activity 15 comments · opened Feb 6, 2026 · closed Apr 27, 2026
💡 Likely answer: A maintainer (claude[bot], contributor)
responded on this thread — see the highlighted reply below.
Bug Description
With Claude Code using Opus 4.6, the system reports "context full" prematurely and /compact fails, leaving the user stuck. First noticed in v2.1.32, still present in v2.1.34.
Steps to Reproduce
- Use Claude Code v2.1.34 with
claude-opus-4-6model - Work normally until message tokens reach ~78k (still only 48% of 200k context)
- Claude reports context is full
- Run
/compact - Compaction fails with error
Error Message
/compact
⎿ Error: Error during compaction: Error: Conversation too long. Press esc twice to go up a few messages and try again.Context State at Time of Error
/context output shows plenty of remaining space:
claude-opus-4-6 · 97k/200k tokens (48%)
Estimated usage by category
System prompt: 3.3k tokens (1.6%)
System tools: 16.5k tokens (8.2%)
Memory files: 3.4k tokens (1.7%)
Skills: 290 tokens (0.1%)
Messages: 77.7k tokens (38.8%)
Free space: 66k (32.9%)
Autocompact buffer: 33k tokens (16.5%)No MCP servers are configured.
Expected Behavior
- Context should not report "full" at 48% usage
/compactshould successfully summarize the conversation- After compaction, work should be able to continue
Actual Behavior
- Context reports full prematurely
/compactfails with "Conversation too long"- User is stuck and cannot continue working
- Only workaround is pressing Escape twice to drop messages or starting a fresh conversation
Likely Cause
The compaction process appears to send the conversation to a smaller model for summarization. When message tokens reach ~78k, this exceeds the summarization model's context window — even though the primary model (Opus 4.6, 200k) has plenty of room. The compaction pipeline may not be scaled for Opus 4.6's larger context window.
Environment
- Claude Code version: v2.1.34 (first noticed in v2.1.32)
- Model: claude-opus-4-6
- Platform: macOS (Darwin 24.6.0)
15 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
May not be a dup of 1. because this isn't in a long conversation. It gets stuck in a single, relatively simple task (run a test and debug it - and the debug isn't that complex)
May not be a dup of 2. as this only started happening in 2.1.32 (2.1.31, and before was not an issue)
Possible dup of 3., but information above may be clearer.
Adding a data point from claude.ai (not Claude Code) that may help narrow this down.
Environment: claude.ai web, Claude Max, Opus 4.6, macOS. 8 MCP integrations connected (Notion, Fireflies, Gmail, Calendar, Drive, Chrome extension, office-addin). 67 tool definitions loaded into every session.
Behavior: Compaction triggers on first or second message when fetching content from MCP connectors (Notion documents, Fireflies transcripts). Compaction bar appears at 27-37% of the progress indicator. This started with the Opus 4.6 rollout on Feb 5 and did not happen at this frequency on Opus 4.5.
Root cause confirmed by Anthropic support (Fin): The compaction system calculates context usage as
input_tokens + cache_creation_input_tokens + cache_read_input_tokens + output_tokens. Thecache_read_input_tokensincludes accumulated reads from multiple internal API calls made by server-side MCP tools, not the actual conversation context. So actual context might be ~63K tokens but the system sees significantly higher usage and triggers compaction.This means anyone using MCP connectors on Opus 4.6 is hitting premature compaction because cached tool definition reads are being counted as conversation context.
Also noting that compaction was temporarily disabled on claude.ai on Feb 5 (same day as Opus 4.6 launch) per status.anthropic.com, which suggests the team is already aware of the interaction.
Happy to provide screenshots of the 27% and 37% compaction triggers if useful.
I am seeing this a lot when using subagents with Opus 4.6, it looks like message tokens from subagents are counted as part of the main message tokens, causing message tokens to get > 100% and compaction fails (see 163% message tokens):
!Image
I quickly run into this bug whenever I spawn multiple subagents.
This is happening so much throughout the day nothing can even be done anymore with Claude code. Even tried reverting to Opus 4.5 and that didn’t fix it either.
I have to use my mac now and I hate that. I only use mac for ios apps. Hope its fixed soon or they can clear the bugs with latest version and windows.
This appears to be a harness issue. Using another model provider hits the exact same problem.
<img width="692" height="411" alt="Image" src="https://github.com/user-attachments/assets/c7091faf-6e5a-4910-96e6-986544481b81" />
Same for me !
Getting this error quite often the last few days. Seems to happen more frequently when I paste screenshots.
Image-heavy workflows make this especially severe
Adding a detailed data point — this bug is particularly disruptive for frontend/UI development workflows that rely on sharing screenshots.
Environment
claude-opus-4-6(standard 200K context)Reproduction pattern
/clearand lose all contextWhy images make this worse
Images are tokenized at
(width × height) / 750tokens and cannot be compressed during compaction. A single Retina screenshot (3840×2160) costs ~11,000 tokens. Four screenshots = ~44,000 tokens that pass through to the summarization model completely uncompressed.So even at low overall context usage, the summarizer's context window overflows because it has to include all the raw image tokens alongside the text it's trying to summarize.
Regression
This was not an issue before Opus 4.6. The same workflow (uploading multiple screenshots for UI review, iterating on frontend code) worked fine on previous Opus versions with the same image sizes and frequency. Something changed in either the compaction pipeline or how image tokens are accounted for with Opus 4.6.
Impact
For anyone doing frontend development, design review, or visual QA — essentially any workflow where you're sharing screenshots — this bug makes Opus 4.6 sessions extremely fragile. You're limited to ~3-4 image uploads before risking a session crash with total context loss.
Affects Desktop App too
This is not limited to Claude Code CLI. The same compaction failure occurs in the Claude Desktop App when sharing multiple images in a conversation with Opus 4.6.
Suggested fix
The compaction pipeline should either:
Sale for me !! Always here in latest Claude code version !! Claude code inusable with screenshots feedback ..
Maybe just opensource Claude Code for realsies so we all can fix these bugs together. I just bumped into this as well. :/
apparently you can give instructions to compact now, so we will see...
Okay, the compact for my context suggested at startup for a 500k conext failed, but this succeeded:
/compact main discussion only, do not include any tokens from sub agents or agent teams except for team lead"Conversation too long" at 48% usage means the session has so much bloat that the compaction prompt itself exceeds limits. The actual content might be at 48%, but progress ticks, file-history snapshots, and duplicate content push the compaction input over.
Cozempic v1.4.1 fires a PreCompact hook that prunes the session before compaction runs. The guard daemon also proactively keeps sessions lean so you rarely reach the compaction threshold.
pip install cozempic && cozempic initThis is a duplicate of #2038, which was fixed as of version 2.1.85.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.