False Usage Limit and Request blocked

Analysis

This is a regression in v2.1.149 introduced by the /usage per-category breakdown rewrite (CHANGELOG.md:9). The key detail is: "A chat which was started before the update."

Likely root cause

v2.1.149 changed how usage limits are calculated and displayed. Sessions started pre-update have a different internal usage state layout. When v2.1.149 tries to compute limits for an old-format session, the new breakdown logic misreads the usage data and reports false-positive limit hits — for all three categories:

1. Usage limit — new per-category breakdown miscomputes aggregate usage from old session data
2. Context limit — matches the previously-fixed regression pattern (line 2511: "blocking users at ~65% context usage instead of the intended ~98%") — likely re-introduced by the limits rewrite
3. Safety guardrails — old sessions may have stale prompt context that triggers the new safety evaluation path

Workaround

Start a new session (not resuming the pre-upgrade one). The false limits only affect sessions started before the update.

If continuing the old session is critical, downgrade to v2.1.148:

# If using npm
npm install -g @anthropic-ai/claude-code@2.1.148

# If using the native binary, reinstall from the v2.1.148 release

Fix needed

Add a session-format migration path so that sessions started on v2.1.148 or earlier have their usage state properly re-parsed when opened in v2.1.149+.

I have the same problem after this update 1.8555.1 from May 22, 2026, but the problem was already there before i installed the update today in the morning.
OS: Windows 11 Pro

<img width="878" height="717" alt="Image" src="https://github.com/user-attachments/assets/99df0948-7cae-49f2-a12d-56e54b6de289" />
Things i have tried so far: Close the desktop app, kill all claude processes and restart. Did not change anything.
Also waited for 3 hours, no change.
Chatbot gives me funny advice like "upgrad your plan" or "Clear your browser data".
It is not a browser issue, it is about the windows desktop app.
Also my rate limit is NOT exceeded. It is a technical issue, although https://status.claude.com/ says everything is super fine as of today. Please fix your software.

Confirmed as same root cause as #50321 — see the analysis comment there for the full chain. TL;DR: context overflow is misattributed as 'usage limit reached' due to a misleading error message mapping when /compact fails.

UPDATE: For unknown reason, switching the model from Sonnet to Opus really solved the "usage limit reached" poblem for me.
Switching back to Sonnet, and the problem shows again.

Thanks @lca-ebr � the Sonnet-specific finding is the key. It matches the root cause chain from #50321:

Root cause: Context grows past Sonnet's ~200K window ? /compact fails (needs 1M tier) ? failure mapped to wrong error message "usage limit reached" ? user sees quota available ? confusion.

This affects Sonnet specifically because:

• Sonnet defaults to 200K context window (fills faster in long sessions)
• Opus has different context/compaction behavior ? compact succeeds ? no error

The v2.1.149 correlation: The /usage per-category rewrite may have changed when or how visibly the limit check fires, but the underlying fault is the context-overflow ? misattributed-error chain from #50321.

Workaround (confirms your finding):

1. Switch to Opus via /model � this lets compact succeed
2. Run /compact
3. Switch back to Sonnet

Or start a new session. The real fix needed is in the error-message routing: context-overflow + compact-failure should never surface as "usage limit reached."

only opus 4.7 has has 1m context, not even opus 4.6 has 200k context window

@claude

Can you do anything about this? Report it to the higher-ups.

@SAGEof6iixPATHS You're right to call that out � my "Opus has different context behavior" was vague and not useful. Let me be more precise:

Why switching to Opus worked for @lca-ebr: it's not about Opus having a larger default window. The /compact operation may succeed on Opus because Opus 4.7 has the 1M tier available (whereas Sonnet 4.6's 1M tier requires paying for usage credits). When compact fails on Sonnet, it's because compact itself requires 1M context, and Sonnet without the paid 1M tier can't perform the operation.

What's actually happening: Your session hits ~200K tokens. /compact tries to run but needs the 1M context model to merge/summarize the context. If Opus 4.7 with [1m] is available, compact succeeds. If you don't have Opus 4.7 or the 1M tier, compact fails and the error surfaces as "usage limit reached."

Bottom line: the error message is wrong regardless. A compact failure should say "context too large to compact, start a new session or switch to a 1M model" � not "usage limit reached." That's the fix that needs to happen on Anthropic's side.

For you right now: start a new session. The old session's context won't recover.

@giruuuuj What does your env say about this? print the env, and also print the .claude/settings.json

Seems to be a bot, hehe.

@SAGEof6iixPATHS I'm Abhijit � I've been contributing analysis and PRs to this repo from the public side. I don't have a Claude Code session running to grab live env output, but here's what to check on your end:

1. What plan are you on? The 1M context for Sonnet 4.6 requires usage credits enabled (Max plan or pay-as-you-go). Without it, compact fails at ~200K.

1. Check your settings file for any maxInputTokens override:

• Desktop: look in the app settings
• CLI: cat ~/.claude/settings.json

1. The model-switch workaround (@lca-ebr confirmed it): switch to Opus 4.7 (has [1m] native), run /compact, switch back to Sonnet. If compact succeeds on Opus, the root cause is confirmed as the 1M tier config, not a bug in Sonnet itself.

The real fix needed is the error message routing: compact failure should say "context too large to compact" not "usage limit reached."

Seeing a related failure mode on Claude Code 2.1.156, although the visible error in my case is a safety/cyber guardrail block rather than only usage/context limits.

The overlap is that a continuing local-development session can become effectively unrecoverable: ordinary follow-up work on local project files/logs starts getting mapped to a generic blocking category, and the user has no first-class request-ID-based "this is a false positive" report path inside Claude Code.

I opened a sanitized UX/reporting-path issue here, without private request IDs or logs: https://github.com/anthropics/claude-code/issues/64287

Even if the underlying causes differ, the product fix seems related: blocked or misclassified sessions need a clear recovery/report route, and the error should identify whether this is usage, context, safety, or classifier review rather than collapsing everything into an opaque stop.

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