[BUG] Usage limit reached despite UI showing low consumption percentages
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Summary
Claude Code displays "Usage limit reached" while the Plan Usage UI simultaneously shows very low consumption across all tracked metrics. The displayed percentages are clearly inconsistent with the actual enforcement happening under the hood.
What's Wrong?
The Claude Code interface blocked all usage (both Opus 4.7 and Sonnet 4.6) while the Plan Usage panel showed:
- 5-hour session limit: ~1% used
- Weekly · all models: ~17% used
- Weekly · Claude Design (Opus): ~34% used
- Weekly · Sonnet only: ~17% used
None of these values are near 100%, yet the system returned a hard block with "Usage limit reached" and an Upgrade prompt. Switching from Opus 4.7 to Sonnet 4.6 did not resolve the issue — confirming this is not a model-specific limit.
Actual Behavior
Hard block on all usage. UI percentages appear to be decorative rather than accurately reflecting actual enforcement state.
What Should Happen?
Usage limits should be enforced consistently with what the UI displays. If the 5-hour session is at 1% and weekly limits are at 17%, the user should not be blocked.
Error Messages/Logs
Steps to Reproduce
- Open Claude Code (desktop app)
- Check Plan Usage panel — all metrics show low percentages
- Attempt to send any message (any model)
- Receive "Usage limit reached" block despite UI showing available headroom
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Sonnet 4.6
Claude Code Version
Latest
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Warp
Additional Information
This makes it impossible to plan or manage usage effectively. If the displayed metrics cannot be trusted, the entire usage tracking UI is misleading paying subscribers. Related to #11810 and #9094 — this issue appears to still be actively affecting users.
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗