[BUG] Weekly limit stays at 99% after Pro → Max 20x re-login; rateLimitTier now correct but counter not recalculated
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?
After upgrading the subscription from Pro to Max 20x, the CLI kept serving the old plan, and after fixing that via re-login the accrued weekly counter was not corrected.
Sequence:
Subscription upgraded Pro → Max 20x. claude.ai Settings shows "Max (20x)".
Claude Code CLI (v2.1.237) continued to report the old plan:
Header line: Sonnet 5 with xhigh effort · Claude Pro
claude auth status → "subscriptionType": "pro"
This matches #43639 (cached subscriptionType / rateLimitTier).
Usage panel during this period:
Current session: 0% used
Current week (all models): 99% used (resets Aug 23, 9pm Europe/Berlin)
Current week (Fable): 4% used
"What's contributing to your limits usage?" → "Nothing over 10% in this period" for the last 24h window.
Ran claude logout + claude login. Now correct:
claude auth status → "subscriptionType": "max"
.claude/.credentials.json → rateLimitTier: "default_claude_max_20x"
The weekly "all models" bar is still at 99%, unchanged. The 5-hour session limit is fine (0%). Only the weekly window is affected — same split as #58101.
Actual workload behind those 99%: roughly three days, Sonnet 5 only (no Opus), at most two parallel interactive sessions. Heavy agentic use, but this is a Max 20x plan with the +50% weekly promo active.
What Should Happen?
Either of the following, depending on how the counter is stored:
If weekly consumption is stored as an absolute quantity and divided by the current tier's ceiling at render time, the percentage should have dropped sharply the moment rateLimitTier became default_claude_max_20x.
If weekly consumption is accrued as a normalized share computed against the tier active at request time, then every request made while the account was misclassified as Pro was billed at roughly 20x its correct weight. In that case a re-login cannot repair an already-accrued window, and the current weekly window needs a server-side recalculation or reset.
Could a maintainer confirm which of the two models is in use? That determines whether this is fixable client-side at all, or whether every affected user needs manual intervention.
Error Messages/Logs
No stack trace — this is quota accounting, not a crash.
claude auth status before re-login:
"subscriptionType": "pro"
after re-login:
"subscriptionType": "max"
$ jq -r '.. | objects | select(has("rateLimitTier")) | .rateLimitTier' \
~/.claude/.credentials.json
default_claude_max_20x
/status → Usage tab, unchanged before and after re-login:
Current week (all models) ████████████████████░ 99% used
Resets Aug 23, 9pm (Europe/Berlin)
Steps to Reproduce
Be on Claude Pro with an authenticated Claude Code CLI session.
Upgrade the subscription to Max 20x on claude.ai. Do not re-login in the CLI.
Use Claude Code heavily for several days. The CLI still reports "Claude Pro" and subscriptionType: "pro" (#43639).
Observe the weekly "all models" bar climbing at Pro-tier rate.
Run claude logout && claude login. Confirm rateLimitTier is now default_claude_max_20x.
Re-open /status → Usage. Expected: weekly percentage recalculated against the Max 20x ceiling. Observed: unchanged at 99%.
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.237
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
Related issues — same family, none resolved:
#43639 — CLI caches subscriptionType and rateLimitTier indefinitely; plan upgrades not reflected. Matches step 2/3 here exactly.
#29579 — After fresh login the subscription is recognized, but the rate limit persists despite low reported usage. Matches step 6 here.
#58101 — After Pro → Max 20x the session limit updates correctly but the weekly limit continues to behave as Pro. Matches the session-vs-weekly split here.
#40340 — Same class of stale-credential rate limiting on Claude Desktop/Cowork.
This report adds the data point that the failure survives a correct rateLimitTier, which the earlier reports could not confirm.