[BUG] Usage limit reached - while still having 93% weekly limit and 100% 5-hour limit

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/50155
2. https://github.com/anthropics/claude-code/issues/45020
3. https://github.com/anthropics/claude-code/issues/45098

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

Found 3 possible duplicate issues: 1. Saying I hit my limit when I haven't (just upgraded plan) #50155 2. [[BUG] CLI completely blocked by "out of extra usage" error despite Max 20x plan at only 10% usage #45020](https://github.com/anthropics/claude-code/issues/45020) 3. [[BUG] FALSE indication that limit has been reached. Primary quota fully available. Extra usage not relevant, yet error indicated that it is the blocker. #45098](https://github.com/anthropics/claude-code/issues/45098) 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

this is happening in the CLAUDE native app ..

same for me , its stuck in claude desktop

Same for me

<img width="2148" height="494" alt="Image" src="https://github.com/user-attachments/assets/fa505bc1-4233-45f0-beac-b08446ce5432" />

same here , on macos and all is up to date.

<img width="491" height="236" alt="Image" src="https://github.com/user-attachments/assets/f8db5e6f-b074-440f-b760-eaea7798c780" />

<img width="843" height="213" alt="Image" src="https://github.com/user-attachments/assets/572b6d7a-3cf0-4048-9fc9-9e16071e02c6" />

the solution when you hit rate limit just bascul to other model whit saving your whole context windows
https://github.com/AbdoKnbGit/claudex

I have also hit this issue:

Bug Summary:
Usage synchronization issue between Claude Code and Claude web
Technical Details:

Claude Code shows 100% usage with blocking
Claude web shows 75% usage with continued access
Reset time displays as "12am Europe/London" instead of rolling 7-day reset
Max plan limits should be shared across all platforms

Steps to Reproduce:

Check usage in Claude Code (shows 100%, blocked)
Check usage in Claude web (shows 75%, accessible)
Note inconsistent reset time display

Expected Behavior:
Usage percentages and access should be identical across both platforms since Max plan limits are shared

Thanks for tracking this issue – I ran into the same problem and want to add some details that might help diagnose it.

Same issue here on a freshly activated Max 5x plan. Web dashboard shows:

• Current session: 0 % used
• Weekly (all models): 1 % used
• Weekly (Sonnet only): 2 % used

Despite this, Claude Code in VS Code returned "usage limit reached" and blocked all input. No specific error code, just the generic message. I upgraded to Max specifically to avoid running into limits this early, and hitting a limit error with single-digit dashboard usage is the opposite of what I paid for.

After further investigation, the actual cause appears to have been context window overflow, not a plan limit at all. The status panel showed "Messages: 783k tokens" against a 200k context window. The /compact command then failed with "Extra usage is required for 1M context", leaving /clear (full context loss) as the only recovery path.

To be clear: I am not complaining about tool usage consuming tokens. Tools cost performance, that is fine. The problems are communication, limit visibility, usability, and the fact that the chat dies when compaction is no longer possible or becomes a paid feature.

1. Misleading error message. "Usage limit reached" for a context overflow made me check my plan, account, and billing for no reason. The error should name the actual cause and the actual recovery path.

2. The chat should not die. When the context grows too large to compact, the user is in a dead end: compaction requires a paid 1M tier, /clear destroys the session. Compaction must always be possible within the user's current plan tier, either by running it within the standard tier, or by triggering it automatically before the context grows past the point where compaction itself can run. Routing recovery through a paid 1M tier is not acceptable.

3. No visibility into limits before they hit. The web dashboard shows plan-level percentages that have no relationship to what actually blocks the user. Context window state is not surfaced prominently in Claude Code. Users cannot plan around limits they cannot see, so proactive warnings well before a blocking threshold are needed.

Happy to provide more details if helpful. Claude Code is genuinely great when it works, which is exactly why this kind of dead end is so frustrating.

Platform: macOS, VS Code extension, Max 5x plan (newly subscribed).

<img width="835" height="309" alt="Image" src="https://github.com/user-attachments/assets/4adbed0c-a17e-4a91-b95b-d5e0ece23af7" />

Same issue here — filed and closed as duplicate of this: #59946

Details from our case (May 15–17, 2026):

• Plan: Claude Max
• Weekly limit: ~33% consumed
• Daily limit: exhausted within a few hours of normal Claude Code usage
• Happened on 2 consecutive days
• No unusual activity — same workflow as previous weeks where limits were fine

This appears to be phantom usage / double-counting in the daily token tracker. Weekly tracking seems accurate but daily is significantly over-reporting. The two numbers are mathematically impossible if they track the same underlying usage.

Adding this data point to help prioritize a fix.

I have a similar issue, added by comment there; https://github.com/anthropics/claude-code/issues/61703

Root cause analysis

The false "usage limit reached" error is actually a context overflow + failed compaction issue, misattributed to the wrong error message.

The chain

1. Context grows past the model's window (e.g. 200k tokens in a 200k window)
2. /compact is triggered but fails: "Extra usage is required for 1M context"
3. The failure is mapped to "usage limit reached" on the client side
4. User checks their plan → quota available → confusion

This matches @ExtraAir's detailed analysis in the comments. The fix from the ExtraAir comment in #50321 is the most accurate root cause description.

The actual bugs

1. Misleading error message — context overflow → compact fail → "usage limit reached" is wrong. Should say: "Context too large for standard tier. Switch to a 1M context model or start a new session."

1. No proactive warning — users don't know context is approaching the compaction dead zone until they hit it. The context bar should turn red well before the point where compact becomes impossible.

1. Compaction should never require a paid upgrade — if compact needs 1M tier, the session should auto-switch to a 1M model for the compact operation (even if just for one turn).

Workaround (immediate)

# If stuck with "usage limit reached" but plan shows quota:
# 1. Switch to a 1M context model via /model
# 2. Run /compact
# 3. Switch back to your preferred model

Or start a new session.

Recurring issue — Windows 11, Pro plan, June 5 2026
Same bug, different platform. Claude Desktop App on Windows 11, Chat tab (not Claude Code CLI), inside a named Project.
What happens:

Manual chat session on technical topics (MCP servers, Amazon SP-API, skill building)
After <30 min of typing, bottom bar shows: "Usage limit reached • limits shared with Claude Code"
Current session: 100% used / Weekly (All models): 33% used
Claude Code statistics: Sessions 0 / Messages 0 / Tokens 0 — CLI never used

Account: Pro plan, Support Conversation IDs: 215474382032800 / 215474589559710
Context: Now seeing the context overflow explanation — this makes sense. My sessions involve long technical conversations with large code blocks and tables, which likely fills the context window and triggers the false limit before the actual quota is reached.
The "limits shared with Claude Code" banner in the Desktop App is misleading — it suggests a categorization bug, but the real cause appears to be context overflow. The banner wording should be clarified.

<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/6f7ddb2e-286e-4022-8b03-e3d1c77f4ae8" />

Bug reproduces on Pro Plan with Desktop App (Windows) - June 7, 2026

I am experiencing the exact same critical defect on my paid Pro subscription for the third consecutive day (June 5, 6, and 7). The lockout behavior is getting progressively worse.

My metrics today:

• Weekly Limit Used: 51%
• Current Session: 100% Used (triggered instantly after less than 15 minutes of standard use)
• Lockout Duration: Forced 3 hours and 43 minutes wait time.

Root Cause Observation:
The issue triggers immediately when using the Windows Desktop App to work on technical environments (configuring MCP servers, unzipping local files, running native PowerShell tools). The system automatically and forcefully tags the interaction with "limits shared with Claude Code", even though I am typing manually into the standard chat UI.

Once this happens, an invisible background tracking loop completely drains the session quota in minutes. Furthermore, this sync state completely corrupts the account profile on the web interface as well, resulting in Conversation not found errors and treating the Pro account as a restricted free/shared tier in the browser.

This is a severe infrastructure issue where background tool execution and MCP integration flags are falsely triggering automated developer environment throttling constraints on standard Pro profiles.

<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/aa2ddb7d-4a36-4ba8-89b5-8bd263c59ab1" />
<img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/60694437-0262-4894-ad3a-ea1068dfd15f" />

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