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

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

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?

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.

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.

1. A global goodwill reset was granted on 2026-07-01 (documented in #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 #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.

+1