[BUG] Max 20x upgrade not reflected in weekly limits — depleting at Max 5x rate or worse (upgraded July 16, 2026)

[Remy-authority]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

I upgraded from Max 5x ($100) to Max 20x ($200) on Thursday, July 16, 2026 (prorated charge confirmed, plan shows Max 20x in settings). Since the upgrade, my weekly usage limits deplete dramatically faster than they did on Max 5x — not 20x more capacity, but effectively less than my previous plan.

What Should Happen?

After upgrading to Max 20x, weekly usage limits should immediately reflect the 20x tier — i.e. roughly 4x the capacity of my previous Max 5x plan, per the Help Center ("you receive your full weekly allowance each cycle").

Concretely: on Max 5x, ~4-5 Opus messages consumed 1% of the weekly Opus limit and my allowance lasted 6-7 days of normal work. On Max 20x, the same workload should consume proportionally less (roughly 16-20 messages per 1%) and comfortably last the full week. Instead, consumption is at ~2 messages per 1% — worse than the cheaper plan I upgraded from.

Expected fix: recalculate the weekly limit counter to the Max 20x tier for accounts that upgraded mid-cycle, and restore/credit the usage lost since the July 16 upgrade.

Error Messages/Logs

Claude AI usage limit reached. Your limit will reset at [date shown in app].
No error in CLI — weekly usage percentage jumps ~1% per 2 Opus messages despite Max 20x plan.

Steps to Reproduce

1. Subscribe to Max 5x plan (baseline: ~4-5 Opus messages = 1% of weekly Opus limit)
2. Upgrade to Max 20x mid-cycle (July 16, 2026 — prorated charge confirmed, settings show Max 20x)
3. Continue identical daily workload (Opus 4.8 primary, Sonnet for subtasks)
4. Observe weekly limit depleting at ~2 Opus messages per 1% — worse than Max 5x
5. Weekly cap reached in 3 days vs 6-7 days previously on the cheaper plan

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Unknown — issue correlates with plan upgrade on July 16, 2026, not with a Claude Code version change.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

• Support ticket open since July 19, 2026, no response after 48h. Ticket ID: [ton numéro]
• Weekly reset date shown in Settings > Usage: [ta date]
• Prior related issues: Weekly Usage Limits Making Claude Subscriptions Unusable #9424 (user upgraded Max 5x → 20x, depletion rate unchanged), Max 20x plan hitting daily limit with reduced usage — limits appear silently tightened (April 28-29, 2026) #54714 (Max 20x limits silently tightened)
• Suspected cause: weekly limit counter/tier not recalculated after mid-cycle upgrade
• Impact: highest-tier paying customer blocked from client work for 4 days

[cannuri]

Do you have DISABLE_TELEMETRY turned on? try to turn it off and see if it works.

[Remy-authority]

Thanks for looking into this. I don’t have DISABLE_TELEMETRY set, so that’s not it, and I don’t think it would explain this anyway, since telemetry is client-side reporting, while the issue is server-side (my weekly usage limit not being recalculated to the Max 20x tier after a mid-cycle upgrade from Max 5x).

To be clear on the core issue: my weekly quota is depleting faster on Max 20x ($200/mo) than it did on Max 5x ($100/mo), with identical usage. This looks like a billing/account-tier sync issue, not a CLI configuration issue. Is there someone on the team who can check my account’s actual weekly limit allocation against my subscription tier?

[COOLak]

Adding a related paid-account reconciliation signal from a separate unresolved Claude billing case, kept public-safe.

This issue asks whether the actual weekly limit allocation matches the paid Max tier after a mid-cycle upgrade. My direct case is a different billing surface, but the owner boundary looks similar:

• manual prepaid / discounted Claude usage-credit purchases fail or fail to commit cleanly;
• automatic usage-credit reloads on the same paid Claude billing setup can still charge successfully;
• user-visible billing/payment state and usable credit / limit / entitlement state diverge;
• automated support routing has not produced a human Billing Platform / payment-operations owner who can reconcile checkout state, payment confirmation state, entitlement state, tier allocation, and credit-ledger provisioning.

This is not the exact same symptom as a Max 5x -> Max 20x weekly-counter problem. The useful common failure class is that paid billing ledger state, subscription tier allocation, entitlement gates, usage-credit / limit state, and support-visible account state can diverge in ways ordinary client-side troubleshooting cannot resolve.

Requested triage path: please route this class of issues to a human Billing Platform / payment-operations plus entitlement owner who can inspect the paid subscription tier, mid-cycle upgrade ledger, weekly limit counter, usage-credit ledger, auto-reload state, manual purchase/commit state, and the support-visible account state together.

Sanitized public incident packet for my related cluster:
https://coolak.github.io/anthropic-claude-billing-incident/

Owner map / reconciliation matrix:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html

I am intentionally not posting card details, bank names, payment IDs, invoice IDs, support IDs, raw logs, screenshots, payment URLs, private support-thread text, or other private account data here.

[Yoshinobu-Suzuki]

Independent corroboration with per-cycle token measurements, and an account history that may be diagnostically useful: I have moved between Max 5x and Max 20x repeatedly, always by upgrading mid-cycle, which is the exact path this issue implicates.

Billing history (JP, tax inclusive):

2026-03-14   $20       Pro
2026-04-13   $219.27   Max 20x
2026-05-13   $110      renewed on Max 5x
2026-05-27   $160.15   mid-cycle upgrade to Max 20x (prorated)
2026-06-27   $110      renewed on Max 5x
2026-07-14   $169.98   mid-cycle upgrade to Max 20x (prorated)

So my most recent upgrade was 2026-07-14, two days before OP's. Two weeks later the behaviour persists.

One detail that pre-empts the obvious explanation: my weekly limit resets Friday 19:00 local, which is unrelated to my billing date. The 07-14 upgrade was a Tuesday. The cycle beginning Friday 2026-07-17 19:00 was therefore a completely clean, full-length Max 20x cycle starting three days after the upgrade, not a prorated or partial one. It still ran out on Wednesday.

Setup: Claude Code as a multi-agent fleet on one workstation. All figures from ccusage, bucketed to the actual 19:00 reset boundary rather than to calendar weeks.

Cycle start      Plan       Total tokens   API-equiv   Outcome
Fri 2026-06-26   Max 5x        1,887M       $1,672
Fri 2026-07-03   Max 5x        1,591M       $1,424
Fri 2026-07-10   upgraded      3,126M       $3,081     (07-14 upgrade)
Fri 2026-07-17   Max 20x       3,569M       $3,198     reached 99%
Fri 2026-07-24   Max 20x       3,533M       $3,240     83% on day 5

Back-solving from the 07-17 cycle (3,569M at 99%) gives an effective weekly capacity of roughly 3,605M tokens on Max 20x.

Against my Max 5x baseline that is 1.9x to 2.3x. Max 20x is documented as 4x the capacity of Max 5x. What I measure is 2x, which is exactly the ratio of the two prices ($100 to $200), not the ratio of the two tiers.

Two caveats, both of which make the case stronger rather than weaker:

1. I cannot confirm I was saturating the cap during the Max 5x cycles. If I was not, the true 5x ceiling was higher than what I consumed, and the 20x-to-5x ratio is worse than the figures above. The numbers quoted are therefore an upper bound on the improvement, not an estimate of it.

2. A global goodwill reset was granted on 2026-07-01 (documented in [FEATURE] Give users control over weekly limit reset timing (configurable reset day, or banked on-demand resets like Codex) #76272), which falls inside my 06-26 cycle and may inflate that row. I have used the 07-03 cycle (1,591M, no known reset) as the conservative baseline; using 06-26 instead only moves the ratio to 1.9x.

Additional detail that may help isolate the cause:

• It is not the per-model sub-limit. Fable sat at 7% for the cycle in which the general weekly cap reached 99%.
• I never exhausted a 5-hour block in the 07-17 cycle. Consumption was spread across 22 blocks with no single block dominating, yet the weekly pool was gone by Wednesday night. See [BUG] /usage: 5h block and weekly limit percentages rise in lockstep (should scale very differently) #77036, which reports the weekly meter advancing in lockstep with the 5-hour block meter. That would produce exactly this shape, and may be the same underlying defect.
• Back-solved ceilings for two consecutive 20x cycles differ by 18% (~3,605M vs ~4,257M) with no change in workload, so whatever the weekly meter counts, it does not track total tokens consistently.

Practical impact: in the 07-17 cycle I lost roughly 40 consecutive hours, about 24% of the cycle's wall-clock, able to do nothing but ask two trivial questions until the reset. I upgraded to 20x specifically to stop that happening, and it happened anyway, nine days after the upgrade.

One controlled test I can offer, in case it helps triage: I am now staying on Max 20x through my next renewal rather than downgrading and re-upgrading as I have previously. If weekly capacity increases at that renewal with no plan change on my side, that would isolate the mid-cycle upgrade path as the trigger rather than the 20x tier itself. I will report the result here either way.

Raw per-block JSON available on request.

[gowy222]

+1

[Willian-Lima]

Similar case: weekly limit not adjusted after Max 5x → Max 20x upgrade

Adding my case here as it matches this issue closely.

• Upgraded from Max 5x to Max 20x.
• Weekly limit appears to be depleting at the same rate as before (or worse), suggesting the weekly allocation was not recalculated for the new tier — only the 5-hour session limit seems to reflect the upgrade.
• Went through the Fin AI Agent chat and later email support twice. The agent repeatedly confirmed that both Max 5x and Max 20x have a weekly limit, but could not confirm whether the weekly value differs between tiers, and was unable to escalate to a human or open a ticket. The email thread was eventually closed automatically with a generic "submit a new request" message, without addressing the actual question.
• Current usage screen (Settings > Usage) at time of reporting: Max 20x plan, weekly limit at 64% (all models) and 58% (Fable), reset Sunday at 14:00.
• Support Conversation ID: 215475440621586

Requesting the same as above: confirmation that the weekly limit is recalculated correctly on Max tier upgrades, and investigation into whether this account's weekly allocation reflects Max 20x or is still computed as Max 5x.

[cheonnamsu]

Adding my case — same bug, independent measurement.

• Upgraded Max 5x → Max 20x on 2026-08-10 ($219.48 prorated charge). Prior monthly charges of $110 on 2026-05-11 / 06-11 / 07-11 confirm Max 5x history.

• First-ever You've hit your weekly limit · resets Aug 19 at 12am (Asia/Tokyo) event in my local Claude Code transcripts appears at 2026-08-14 09:44 JST — 34 hours into the first full Max 20x week. No weekly-limit hit exists in any preceding week I have transcripts for (going back to 2026-07-22).

• Local Claude Code transcript analysis, priced at API list rates for comparison:

  Week starting (Wed 00:00 JST reset)	Plan	Total list-priced	Fable-5 only	Weekly-limit hit
  2026-07-22	Max 5x	$2,214	$1,080	No
  2026-07-29	Max 5x	$2,614	$734	No
  2026-08-05	Max 5x → 8/10 upgrade	$3,222	$1,593	No
  2026-08-12	Max 20x (capped at 34h)	$5,629	$1,920	Yes, 2026-08-14 09:44 JST

• Observed ratio: overall 1.75× (5,629 / 3,222), Fable-5 alone 1.2× (1,920 / 1,593). Expected on a Max 5x → Max 20x tier change: ~4×. My numbers align with @Yoshinobu-Suzuki's back-solved ~2× ratio and match the price ratio ($100 → $200), not the tier ratio.

• Financial impact: forced to buy $808.50 of one-time credit top-ups within ~48h of hitting the cap to keep working ($99 + $49.50 + $220 + $220 on 08-14, $220 on 08-15 — all visible as separate invoice lines from the subscription).

• Support flow so far mirrors @Willian-Lima's exactly — Fin AI Agent → escalation → human agent (Conversation ID 215475493810406, still waiting). The first-line reply insisted refunds require subscription cancellation, which contradicts Anthropic's own help article "Request a refund for a paid Claude plan" ("Requesting a refund doesn't cancel your subscription. To avoid future charges, you'll also need to cancel.").

Same ask as the OP: please confirm the actual weekly-limit tier provisioned on my account after 2026-08-10 and reconcile.

[amidan99]

same here
I upgraded to x20 and I'm close to session limit even though I didn't make anything heavy and only running about 2 sessions parallel
it's impossible to hit limit that fast with only 2 sessions

[LawJolla]

Same bug. Upgraded from 5x to 20x, no increase in weekly Fable limit or overall weekly limit.

[cdavaz]

I just upgraded from 5x -> 20x and am experiencing the same issue, it seems there was no increase in my weekly Fable limit. For users paying $200/mo the best support we can get is through a Github issue?

[cheonnamsu]

Follow-up on my earlier comment. Two clarifications:

1. The +50% Claude Code weekly-limit promo covers both my comparison periods. Both my Max 5x weeks (2026-07-22, 07-29, 08-05) and my first full Max 20x week (2026-08-12) fall entirely within the ongoing +50% promo window (announced 2026-07-13 by @ClaudeDevs, most recently extended through 2026-08-31). Since the same boost applies to both sides of the comparison, it does not distort the tier ratio.

2. Cleaner pre-cap number for the Max 20x week. In my earlier post I reported the whole 8/12 week at $5,629 list-priced (34 h pre-cap + partial credit-charged consumption after). The more comparable figure to the Max 5x weeks — which never hit the cap — is the pre-cap only consumption on 8/12–14, which is $5,084 list-priced (2026-08-12 00:00 → 2026-08-14 09:44 JST). Against the Max 5x maximum of $3,222 (never hit cap), the ratio is 1.58×, versus the expected 4× tier ratio. Consistent with @Yoshinobu-Suzuki's independent back-solve.

The 2026-08-31 promo end will drop everyone's Claude Code cap by ~33%, but the underlying bug — Max 20x provisioned at Max 5x-adjacent throughput — remains and will be visible again in the first full post-promo week.

[shawn-j]

I have the same bug, with a data point that pins down the promo confound others here have already flagged.

• Upgraded Max 5x → Max 20x mid-August 2026 (prorated charge confirmed, Settings shows Max 20x).
• • Per @cheonnamsu's Aug 19 point: the +50% Claude Code weekly-limit promo (through Aug 31) applies to both the Max 5x and Max 20x tiers, so it cancels out of a before/after comparison rather than explaining one.
• • • I keep an independent, code-level log of my own Claude Code token throughput (a separate local tally, not the in-app usage meter). It shows a clear ~5x drop right after Aug 17: 683,152,061 tokens / 4,328 assistant messages on Aug 17, falling to 126,609,207 / 722 (Aug 18), 117,442,336 / 758 (Aug 19), and 136,138,498 / 998 (Aug 20) — all on the Max 20x tier.
• • • • Despite that ~5x drop in my own measured usage, the weekly quota bar in Settings > Usage kept depleting at essentially the same rate as before the upgrade.
        If the 20x tier were actually applying, a 5x drop in real usage should make the weekly bar barely move. It didn't. Adding this in case the token-level comparison is useful next to the billing/message-count numbers already posted above.