Claude Opus 4.6 1M context: self-reported degradation starting at 40%, recommending restart by 48%

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/34332
2. https://github.com/anthropics/claude-code/issues/32659
3. https://github.com/anthropics/claude-code/issues/28721

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

Honestly this seems like the same model with a 5x long reported context, just compacting and losing its mind along the way as usual.

I run Opus 4.6 across hundreds of sessions daily in an autonomous loop. The degradation pattern you describe matches what I've observed — here are concrete mitigations that help:

1. Compact aggressively at ~30% context, not 50%
Don't wait for auto-compression. Use /compact proactively with a summary of key decisions. The auto-compression loses important nuance.

2. Offload investigation to subagents
Heavy tool-call sessions (Bash, Read, Grep chains) bloat context fast. Delegate investigation/exploration tasks to subagents — they get their own clean context and return only results. This keeps your main session lean.

3. Checkpoint state to files, not conversation memory
Write architectural decisions and current state to a file (e.g., mission.md or todo.md) as you go. When you compact or restart, the agent reads the file instead of relying on conversation history.

4. Screenshots are context killers
Each PNG screenshot consumes thousands of tokens. If you're doing browser automation with screenshots, that explains hitting degradation at 40% — the effective text context is much smaller.

5. For codebase-wide refactors, plan-then-execute in fresh sessions
Plan in session 1 → write the plan to a file → execute in session 2. Don't iterate for hours in one session.

The 1M context is real, but effective high-quality context for iterative development with heavy tool use is closer to 300-400K in my experience. Multimodal content (screenshots) reduces it further.

@yurukusa yes I also have my own process that covers most of what you suggested. My observations above were found in testing the new 1M context model to understand its limits vs previous models. Previously I would not proceed beyond the endpoints self reported 75% usage, at which point I would have it summarize continuation details to a file, and pick that up with a fresh context. This issue is primarily to report and to get feedback around the reported usage, and how that aligns to model capability. To me the model seems barely more capable at around 20% than the previous model at 75%.

That's a good data point. On the 200K model, I see measurable instruction-following degradation past ~150K tokens (75% of 200K), which aligns with your 75% threshold.

If the 1M model behaves similarly at 20% reported usage (~200K actual tokens), that would suggest the effective context ceiling hasn't actually increased — just the reported capacity. Would be worth testing whether compacting at the same absolute token count (~150K) gives better results than going by the percentage.

I prefer to /compact or even /clear at 20% (200k). Same as before introduction of 1m ctx window, agent's performance degrades after 180-200k. In essence this 1m is just a claim. It is not supported by real increase of stx window that user can benefit from.

@Tudor-MS yeah agreed, this is some marketing nonsense. I just have a longer progress bar now lol.

This weekend was horrific. It was like Claude got a lobotomy. The 1M context window was useless when it cannot reason its way out of a wet paper bag. The degradation is not subtle, not in the least. Claude went from having a strong intuition about what you were asking it which it has almost completely lost. It jumps to conclusions, wildly wrong ones, in astonishing ways I've never seen before.

@nsxdavid yes agreed. I have switched back to regular Opus (200k context window) as I'd rather not accidentally cross a compaction point. I wrote a handy status line script that shows me the context as a progress bar. You may find it useful. https://github.com/mannewalis/claude-status-line

Fully agree with the degradation. Have been using it for coding / reasoning, and even with max effort, very clear examples and target states it still gets lost in its own reasoning. The previous model definitely would have solved these issues better. It seemed "sharper" and understood the logic chains required to get to a target state better. Planning mode (and effort: MAX) helps somewhat, but is now needed for things that it would previously have easily done.
Gut feel: it gets "lost in its own mind" (context)

Ok this one is new lol

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

✻ Cooked for 1m 17s

🤖 Opus 4.6 (1M context) | Context (used) 18% [███▌ ]

The 18% is reported from the status line json object from Anthropic. And is telling, it aligns almost perfectly with observations.

This is happening to me consistently now, wonder if an update broke the 1M context model. I have noticed it varies as to which is available, it automatically switched to Opus 200k for me, then that disappeared and I noticed the default was now Sonnet, so I switched back to Opus 1M, and now I am getting this consistently.

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

🤖 Opus 4.6 (1M context) | Context (used) 16% [███▏ ]

I am using it in vscode, and have run a lot of sessions since yesterday where I have kept it under 200k (of 1m). That combined with high / max reasoning seems to have it working normally. https://github.com/venkata-arista/claude-statusline-vscode helps.
I wonder if the 1m model is a diff model, or just the same model with a larger context window, which give it too much information to handle, and it is not stringent / focused enough in its logic due to too much context.

Context degradation at 40% on 1M sessions is caused by low signal-to-noise ratio — the context fills with progress ticks, stale tool results, duplicate system-reminders, and old file reads that dilute the useful content.

Cozempic v1.4.1 keeps the signal-to-noise ratio high by continuously pruning low-value content. 17 strategies target different bloat types: progress-collapse (40-48%), stale-reads (file reads superseded by later edits), system-reminder-dedup, tool-output-trim. The guard daemon runs these automatically.

pip install cozempic && cozempic init

Also detects 1M context models automatically — no manual --context-window needed.

+1 on this. My colleagues and I experienced noticeable degradation at ~47% context on Claude Opus 4.6 [1m] with the same symptoms listed in this Issue's description.

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