1M context + rate limits = unrecoverable state (compaction blocked)

The short version

The 1M context window is one of the most important features you've shipped. It changes how I work. I'm writing this because I want it to succeed, and right now it has a failure mode that makes it dangerous to use.

What happened

I'm a Max subscriber running Claude Code (v2.1.45) on a client deliverable. I had three sessions running on Opus 4.6 with 1M context. All three were doing real, productive work — one on creative strategy, one building prototypes, one orchestrating.

After about an hour, I hit rate limits across all sessions simultaneously. This is understandable. Rate limits exist for a reason.

Here's what's not acceptable: I couldn't recover.

• I couldn't compact any session because compaction requires an API call, which is rate-limited.
• I couldn't switch models because the 1M option disappeared entirely.
• I couldn't do anything in any session. All three were frozen with large contexts I couldn't shrink.
• The sessions had accumulated hours of creative context — client corrections, design decisions, technical state — that would be lost if I killed them.

I was locked out of my own work with no path back in.

Why this matters

The value proposition of 1M context is: don't lose your thread. Keep working without compaction destroying continuity. For creative and client work, this is transformative. I've measured compaction context loss at 42% in some sessions. The 1M window fixes that.

But if the feature that prevents context loss can itself become a trap where you lose everything, the value proposition inverts. The thing that was supposed to protect my work became the thing that killed it.

I ended up having to extract the session histories with a separate standard-context session, write recovery briefs manually, and prepare to kill the stuck sessions and start over. That's about 45 minutes of recovery work on a tight client deadline. Real money. Real time.

What I think needs to happen

1. Compaction should be exempt from rate limits, or at least given priority. If a user is rate-limited, the single most helpful thing they can do is compact their context. Blocking that creates an unrecoverable state.

1. Rate limit warnings before you hit the wall. If I'd known I was approaching the limit, I could have compacted one session proactively and kept working. Instead it went from "everything's fine" to "nothing works" instantly.

1. Graceful degradation, not hard cutoff. When rate-limited, allow at minimum: compaction, model switching, and session management. Even if new prompts are blocked, let me manage my own sessions.

1. Don't remove the 1M model option during rate limiting. I couldn't even select the model anymore. That's confusing and feels like a punishment rather than a temporary constraint.

1. Document the interaction between 1M context and rate limits. Right now there's no guidance on how many concurrent 1M sessions are safe on Max. I found out the hard way.

What I appreciate

The 1M context window is magical. In the hours before the crash, I had three sessions maintaining perfect continuity on a complex creative project. No compaction loss. No re-explaining decisions. No identity drift. It was the most productive I've been with Claude Code.

That's why the failure hurt. It wasn't a toy breaking. It was a professional tool failing during professional work.

I'm a paying Max subscriber who uses Claude Code 7 days a week (25-day streak, 256 sessions in the last 7 days). I'm not trying to abuse the system. I'm trying to ship work for a client. The 1M context window is the right feature. The rate limit interaction just needs a recovery path.

Environment

• Claude Code v2.1.45
• Opus 4.6 (1M context)
• macOS Darwin 25.2.0
• Claude Max subscription
• Three concurrent 1M sessions