[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

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.

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.

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

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

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?

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.

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.

I don't have granular token logs to share, but here's the pattern: I hit the weekly limit at roughly the same point in the cycle regardless of tier, while shipping the same amount of work each time. If the tier's multiplier actually applied to the weekly cap, that timing should shift meaningfully higher on Max 20x, but it doesn't.

For what it's worth, the session limit scaling does seem real. On Max 5x I'd occasionally hit the 5 hour session cap, on Max 20x I never do. So the "20x" claim checks out for the session limit. It's specifically the weekly limit that doesn't move the way the tier name implies.

Worth noting where the "5x" and "20x" language actually comes from. Anthropic's own help center (https://support.claude.com/en/articles/11049741-what-is-the-max-plan) explicitly scopes the multiplier to the 5 hour session limit only: "Max 5x provides five times more usage per session than the Pro plan... Max 20x provides 20 times more usage per session than the Pro plan." The same article then says separately, with no multiplier attached: "Max plans also have a weekly usage limit that applies across all models."

So the question stands. Where, if anywhere, is it documented that the weekly limit scales by the same 5x/20x ratio as the session limit? If that documentation doesn't exist, then Max 20x isn't actually a 20x plan overall. It's a 20x session limit bundled with an underspecified (and per the data above, roughly 2x) weekly limit. For some of us that works out to paying double for the same effective weekly capacity as Max 5x.

By contrast, I don't experience this with Codex under comparable usage. If this isn't addressed, I'll be cancelling.

Follow-up on the post-renewal test I promised in my Jul 28 comment.

Setup: stayed on Max 20x through the renewal (~Aug 27), no 5x↔20x switching this time. Weekly reset for this account is Fri 19:00 JST.

Same-time pair reading, Sat Sep 6 21:57 JST (≈51 h into the first full post-renewal week):

• /usage: Weekly (7 day) 42%, Session (5hr) 17%, Weekly Fable 49%
• client-side tokens since the Fri 19:00 reset (from local transcripts, deduped by message/request id, input+output+cache-create+cache-read): 1.45B total (opus-5 1.12B / sonnet-5 0.18B / fable-5.1 0.15B), of which 0.144B in the current 5h block

Implied capacity = tokens / percentage:

• weekly: 1.45B / 0.42 ≈ 3.45B — essentially the same ~3.6B I inferred in July on 20x
• 5h block: 0.144B / 0.17 ≈ 0.85B → the weekly bucket ≈ 4 five-hour blocks (matches #77036)

My two full 5x weeks were 1.89B / 1.59B (avg 1.74B), so 20x ≈ 2.0× of 5x, not 4×. Both sides use the same client-side token accounting, so cache-read weighting cancels out in the ratio.

Conclusion: this is not specific to the mid-cycle upgrade path. Staying on 20x across a renewal gives the same ~2× of 5x as before. Whatever the cause, it is the 20x tier's effective weekly capacity as delivered, at least on this account.

Caveat: there was a one-off usage reset around Sep 2 (JST). The reading above is taken from the regular Fri Sep 4 reset, so it is unaffected.

Method note for anyone else measuring: no need to wait for the week to run out. A same-time reading of /usage weekly % vs your local token count since the reset gives the capacity directly (ccusage blocks --json re-bucketed at your reset time, or the transcript JSONL directly).

Follow-up with a fresh same-time pair, plus what I think is the clearest framing of this bug so far.

Setup: Max 20x, unchanged since the Aug 27 renewal, no tier switching. Weekly reset for this account is Fri 19:00 JST, so the current window opened Fri Sep 11 19:00 JST.

Same-time pair reading, Sat Sep 12 11:39 JST (~17 h into the window):

• /usage: Weekly (7 day) 11%, Session (5hr) 26%, Weekly Fable 3%
• client-side tokens since the Fri 19:00 reset (local transcripts, deduped by message/request id, input + output + cache-create + cache-read): 0.795B (opus-5 0.747B / sonnet-5 0.048B)
• of which inside the current 5h block (opened 10:30 JST): 0.231B

Implied capacity:

• 5h: 0.231B / 0.26 ≈ 0.89B
• weekly: 0.795B / 0.11 ≈ 7.2B

The 5h figure reproduces my Sep 6 reading almost exactly (0.144B / 0.17 ≈ 0.85B then, 0.89B now — within 5%). So the method is stable and the Max 20x session cap is a consistent ~0.87B tokens.

The structural point. A week contains 33.6 five-hour blocks. My weekly pool is worth about 8 of them. So I can run at the session cap for roughly 24% of the week; for the other 76% the session limit is unreachable, because the weekly pool is gone first.

That is, I believe, exactly what @dlaszlo described on Aug 29 — "On Max 5x I'd occasionally hit the 5 hour session cap, on Max 20x I never do." The session limit did scale with the tier. The weekly limit did not scale by the same factor, so the ratio between them changed, and the session cap stopped working as a usable ceiling. On Max 5x the session limit paced me. On Max 20x nothing paces me until the week is simply over — which is a worse failure mode, because it arrives without warning in the middle of long-running work rather than as a 5-hour pause.

A caveat I want to state explicitly, against my own case: my implied weekly capacity moved from ~3.4B (Sep 6) to ~7.2B (today) while the 5h capacity stayed put. From the outside I cannot tell whether that is the temporary weekly-limit increase in effect this month, meter lag on a window only 17 h old, or a change in weekly accounting. I would trust the 5h number and treat the weekly number as needing confirmation from your side.

That opacity is itself part of the complaint: there is no documented unit for the weekly percentage, so a subscriber has no way to verify the capacity of the tier they are paying for, and no way to pace against it.

Ask: please publish (a) the unit the weekly percentage is denominated in, and (b) the intended weekly-to-session ratio for each tier. If ~8 session-blocks per week is the intended shape of Max 20x, please say so plainly and I will plan around it. As it stands, the "20x" in the tier name describes the limit I never reach.

Author here, and I am back with measurements rather than impressions.

Same work, same machine, same pipeline. Two evenings apart. And here is the part that makes no sense: the cheaper model burned far more of my allowance.

| Date | Work done | Model used | List price per Mtok | Tokens processed (local Claude Code logs) | Weekly limit consumed |
|---|---|---|---|---|---|
| 7 Sep 2026 | 2 sites built by my agents | Fable | $10 in / $50 out | 772 M | ~14-15 % |
| 10 Sep 2026 | 2 sites, same pipeline | Opus | $5 in / $25 out | 1 401 M | 39 % |

So on 10 September I used the model that costs half as much per token, processed 1.8x the tokens, and my weekly allowance went down 2.6x faster. Those three numbers cannot all be right at the same time.

Three questions that need an answer from Anthropic:

1. Why did an identical pipeline consume 1.8x more tokens on Opus than on Fable? Nothing changed on my side: same prompts, same scripts, same repository, same steps.
2. What multiplier is actually applied to Opus versus Fable against the Max 20x weekly allowance? It is published nowhere, and my measurements suggest Opus is weighted far more heavily than its list price implies.
3. Why does my machine record a 1.5x cost increase while your counter deducts 2.6x?

For context: I am on Max 20x, billed 220 EUR per month, and I use Claude Code every day for production work. This is the second metering problem I report on this account (support ticket 215475147879643 in July, this issue, still open, corroborated since by five other users).

What support gave me this week: an automated reply refusing compensation for "service degradation", then a redirect into a conversation thread that does not accept new messages.

What I am asking for, precisely:

• the per-model breakdown of my weekly consumption for 5-12 September, with the multiplier applied to each model;
• an explanation of the three points above;
• compensation for the period.

Debugging your metering is not my job. I pay for a tool that works and for accounting I can trust. Right now I have neither, and the weekly allowance is cut again on 14 September.

Author again. Since the measurements above will probably get the same treatment as my July report, here is the full picture, and my conclusion.

1. The bugs arrive right after I pay. Every month.
My receipt for this billing cycle is dated 10 September 2026. My metering went off the rails on 10 September 2026. In July, the day I upgraded from the $100 plan to Max 20x, my allowance became smaller than on the cheaper plan (that is this issue, still open two months later). I do not believe in coincidences that repeat on every invoice.

2. "20x" is advertising, not a number.
Measured on my own account: the Max 20x plan gives me roughly 1.7x the allowance of the $100 plan, for 2.4x the price. I have never seen the "+50 % weekly boost" you announced, and you are now cutting it to +25 % on 14 September. Nobody at Anthropic has ever emailed me to explain a single one of these changes.

3. The gauges are unreadable.
Some days my work lands in the Fable gauge, some days in the weekly limit, some days in neither. Last week I hit 100 % of my weekly limit, got a fresh allowance for 48 hours that evaporated at a speed I had never seen, and no one can tell me why. I am paying 220 EUR a month for an accounting system I cannot read and you cannot explain.

4. Opus quality collapsed on 8, 10 and 12 September.
Same prompts, same repositories, same tasks I run every day. On those days the most expensive model on the plan produced work I had to throw away. Your status page confirms elevated errors on Opus on 2, 3, 10 and 11 September. Nobody warned paying users.

5. Support does not exist.
This week I got: an automated agent that refused compensation for "service degradation" without reading my ticket, then a redirect to a "conversation" that does not accept new messages. In July, billing@anthropic.com answered that the mailbox is no longer monitored. That is not a support organisation, that is a wall.

6. Your own product told me to leave.
When I asked Claude Code to explain what was happening to my allowance, it ran the numbers, found the same discrepancy you see in the table above, and advised me to migrate my repositories to Codex so I could keep working. I have never seen a product recommend its competitor to a paying customer. It was right.

Conclusion. I paid 220 EUR for a product that, this month, is not worth 100. I am asking for a refund of the current billing period, in writing, from a human being. And regardless of your answer, I am moving my production to ChatGPT / Codex. Two months, two metering incidents, zero explanations: I am done debugging your billing on my own time.

Author again. One more thing needs to be on the record here, because it answers the question everyone in this thread is asking: does anyone at Anthropic actually read these?

Here is the complete history of what Anthropic answered me about this bug, from my mailbox, dates included.

| Date | Channel | What Anthropic answered |
|---|---|---|
| 19 Jul 2026 | In-app ticket 215475147879643 | Nothing. |
| 22 Jul 2026 | billing@anthropic.com | Auto-reply: "This inbox is no longer being monitored." |
| 22 Jul 2026 | ar@anthropic.com | Forwarded to support@anthropic.com within 2 hours. Then nothing. |
| 6-7 Aug 2026 | In-app chat, conversation 215475326422524 | Bot: "We're transitioning your question to one of our human support agents." Then I was told I could no longer use Fable and should buy usage credits. |
| 14 Aug 2026 (23 days later) | In-app chat + support@mail.anthropic.com, sent by a human agent | The only substantive reply in two months: a canned "how your limits work" template. Session limits reset every five hours. Weekly limits cap all models. Use Sonnet instead of Opus. Group your questions. Buy usage credits. Signed "Anthropic Support", with an apology for the delay: "we're working hard to restore our typical response times." |
| 17-18 Aug 2026 | In-app chat, bot | "Was the last response able to solve your query? I haven't heard back, I hope this means we were able to resolve it. I'll be closing this out." Ticket closed as resolved. Nothing had been answered. |
| 12 Sep 2026 | support@mail.anthropic.com, twice, with the measurements posted above | Auto-reply: "handed to our human support team, it won't be today." |
| 19 Jul to 12 Sep 2026 | This GitHub issue, 17 comments, 14 independent users | Not one word from Anthropic. |

Read the 14 August reply again. I never asked how limits work. I reported that the tier I pay for is not applied. The answer was a user manual, plus the advice to use a cheaper model, plus the advice to buy credits on top of a 220 EUR plan. Not one sentence about the bug. Not one sentence about the "20x". Not one sentence about compensation. Twenty-three days for that, sent by a human being, and four days later a bot closed the ticket as resolved.

So to everyone who wrote here since July, and to anyone who lands on this issue after hitting the same wall: this is the level of support you get on the most expensive consumer plan Anthropic sells. A bot, a dead mailbox, a template three weeks later, and a public bug report that nobody from the company has acknowledged in two months.

I am leaving the measurements, the dates and this timeline here so the next person does not have to spend two months collecting them.

Author again. One more thing needs to be on the record here, because it answers the question everyone in this thread is asking: does anyone at Anthropic actually read these? Here is the complete history of what Anthropic answered me about this bug, from my mailbox, dates included. Date Channel What Anthropic answered 19 Jul 2026 In-app ticket 215475147879643 Nothing. 22 Jul 2026 [billing@anthropic.com](mailto:billing@anthropic.com) Auto-reply: "This inbox is no longer being monitored." 22 Jul 2026 [ar@anthropic.com](mailto:ar@anthropic.com) Forwarded to [support@anthropic.com](mailto:support@anthropic.com) within 2 hours. Then nothing. 6-7 Aug 2026 In-app chat, conversation 215475326422524 Bot: "We're transitioning your question to one of our human support agents." Then I was told I could no longer use Fable and should buy usage credits. 14 Aug 2026 (23 days later) In-app chat + [support@mail.anthropic.com](mailto:support@mail.anthropic.com), sent by a human agent The only substantive reply in two months: a canned "how your limits work" template. Session limits reset every five hours. Weekly limits cap all models. Use Sonnet instead of Opus. Group your questions. Buy usage credits. Signed "Anthropic Support", with an apology for the delay: "we're working hard to restore our typical response times." 17-18 Aug 2026 In-app chat, bot "Was the last response able to solve your query? I haven't heard back, I hope this means we were able to resolve it. I'll be closing this out." Ticket closed as resolved. Nothing had been answered. 12 Sep 2026 [support@mail.anthropic.com](mailto:support@mail.anthropic.com), twice, with the measurements posted above Auto-reply: "handed to our human support team, it won't be today." 19 Jul to 12 Sep 2026 This GitHub issue, 17 comments, 14 independent users Not one word from Anthropic. Read the 14 August reply again. I never asked how limits work. I reported that the tier I pay for is not applied. The answer was a user manual, plus the advice to use a cheaper model, plus the advice to buy credits on top of a 220 EUR plan. Not one sentence about the bug. Not one sentence about the "20x". Not one sentence about compensation. Twenty-three days for that, sent by a human being, and four days later a bot closed the ticket as resolved. So to everyone who wrote here since July, and to anyone who lands on this issue after hitting the same wall: this is the level of support you get on the most expensive consumer plan Anthropic sells. A bot, a dead mailbox, a template three weeks later, and a public bug report that nobody from the company has acknowledged in two months. I am leaving the measurements, the dates and this timeline here so the next person does not have to spend two months collecting them.

I’m another Max 20x subscriber with a similar support experience. I submitted my complaint on September 1. Nearly two weeks later, I still have no substantive human response. The bot initially confirmed that my complaint had been forwarded to human support and successfully placed in the queue. When I followed up, it repeatedly said it could not initiate any human handoff.

My complaint concerns the presentation of Max 5x versus Max 20x and the "Save 50%" claim. As a customer, I cannot reasonably interpret those together as anything other than four times the usage allowance for twice the price - meaning half the price per unit of usage. If that comparison applies only to five-hour sessions, while separate weekly caps materially change how much usage customers actually receive, that qualification needs to be clearly explained before purchase.

I asked for a clear explanation of the weekly entitlements and a manual review of my request to refund the Max 20x premium over Max 5x for two billing periods. Those questions remain unanswered.

Anthropic’s own support policy (https://support.claude.com/en/articles/9015913-how-to-get-support) explicitly states:

Pro and Max plans, Team and Enterprise plan owners, and Console Admins You have full access to: […] * Further assistance from our Product Support team

The same page explains that Fin forwards issues requiring investigation or input from that team. My complaint requires an account review and a reimbursement decision. The bot acknowledges that it cannot provide either, yet also claims it cannot arrange a human handoff. How is a paying customer supposed to get this resolved?

I’m also paying $200/month for ChatGPT while evaluating a switch. In my own coding work, I’m currently more satisfied with Astra’s results, and I find that my usage allowance lasts noticeably longer.

I subscribe as an individual consumer. The continued lack of a substantive response is precisely what is pushing me toward filing a complaint with the relevant consumer protection authority. I would ask it to examine the pricing claims, request the underlying usage-entitlement information that Anthropic has failed to provide to me, and investigate how my complaint was handled: whether I received a substantive response and whether the promised referral to human support actually took place.

This comes across as an arrogant and dismissive way to treat paying customers. At $200 a month, clear information about what I’m buying and a meaningful response to a billing complaint are basic expectations. Given my experience with the alternative, Anthropic is making it increasingly difficult to justify renewing.

Thank you dlaszlo. Your point is the key one: Anthropic's own support page promises Max subscribers "further assistance from our Product Support team". Fifteen of us here, two months, zero contact with that team. I will add this written promise to my pending support case. Anyone filing with a consumer authority: this thread carries the dates and measurements you need.

I encountered the same issue after upgrading from Max 5x to Max 20x on September 14, 2026.

Actual behavior

Immediately after the upgrade, the All Models weekly usage indicator jumped to 100%, even though I had not used Claude between checking the indicator and completing the upgrade.

My account correctly displays the Max 20x plan, and the billing system generated a prorated invoice that credited the unused portion of my Max 5x subscription. However, I remain blocked by the weekly usage limit.

Expected behavior

Upgrading to Max 20x should apply the new quota entitlement to the current usage period. The upgrade should not cause the weekly usage indicator to increase or immediately block the account.

Troubleshooting performed

I have already:

• Logged out of Claude Code using /logout
• Signed out of claude.ai
• Closed and reopened all Claude clients
• Signed back in through a fresh browser session
• Confirmed that the account displays the Max 20x plan

The issue persists, and the All Models weekly usage indicator still shows 100%.

Possible cause

The billing system appears to have processed the upgrade correctly, but the usage service may have failed to migrate the account’s weekly quota from Max 5x to Max 20x. Alternatively, the existing usage may have been recalculated incorrectly during the plan change.

Requested investigation

Could Anthropic please:

1. Verify that the Max 20x quota entitlement and the correct rateLimitTier are active on the backend.
2. Confirm that the usage service is applying the Max 20x weekly allowance.
3. Recalculate the current weekly usage against the correct entitlement.
4. Correct or reset the usage counter if the plan migration caused an incorrect calculation.
5. Investigate why upgrading to a higher-tier plan can cause the weekly usage indicator to jump to 100%.

Impact

This issue has left me unable to use Claude, even though I upgraded specifically to obtain additional capacity.

Anthropic support has acknowledged that this behavior appears abnormal and has escalated the case for human review.

Support reference

Anthropic support conversation ID: 215475929553247

Same pattern, one more data point. Upgraded Max 5x → Max 20x on 2026-09-15 around 11:00 (settings show Max 20x, prorated charge went through).

Unlike @capitaletech's case the weekly bar reset to zero on upgrade. It then drained at nearly the old pace on the same project and the same kind of work: about 10 % in the first ~10 hours on 20x, versus about 60 % in ~41 hours on 5x the weekend before. The weekend ran under the +50 % Claude Code boost and today runs under the +25 % one that replaced it on 14 September, so part of the difference is that cut, not the tier. Either way it is in the range @Yoshinobu-Suzuki and @cheonnamsu measured, and nowhere near 4×.

Support: Fin (conversation 215475947257536) stated it cannot see my tier, cannot verify the weekly allocation, cannot escalate, cannot credit, and cannot confirm a human will reply. Report "documented". Same loop as above.

Two questions, the same as this thread's: what weekly capacity is actually provisioned on a Max 20x account, and is it applied on a mid-cycle upgrade. A number would settle it.

@erpland hah hi sibling, same date, same upgrade, same outcome

@erpland hah hi sibling, same date, same upgrade, same outcome

same bar, lighter wallet 🤷‍♂️

same sadness that we keep adding anecdotal evidence, (well you lot, I just +1'd) and getting ignored

Two updates.

1. Correction to my Sep 6 and Sep 12 comments. I wrote "renewal ~Aug 27". My invoices show the 20x renewal was Aug 13 (the July 13 upgrade moved my billing anchor to the 13th). Both pair readings are still post-renewal with no tier switching, so nothing in the conclusion changes; only the date was wrong.

2. Escalation status, for everyone still adding data here. As of today (Sep 17) this issue has 25 comments from 15 subscribers and no reply from any Anthropic member or collaborator. It carries only the bug label, no area:cost, and no assignee, so it is not in anyone's queue. The related #77036 was stale-closed on Sep 15 after one auto-generated triage. The only usage-limit issue with Anthropic engineers assigned is #16157 (oncall), so I have:

• cross-posted the consolidated measurements there and tagged the three assignees: https://github.com/anthropics/claude-code/issues/16157
• emailed the Claude Code team address that was posted publicly on #16157 for account-level rate-limit reviews, with a dossier that bundles every testimony in this thread (dated, with the support conversation IDs you posted), my measurements, and my invoice history.

If you want your case included in any follow-up, keep posting here with dates and numbers; I will keep the dossier in sync with this thread.

A brief update on my support experience: I eventually received a reply. Support took steps to help with my individual situation, which I appreciate. They also appear to be handling a heavy workload.

They did not address my question about how the weekly allowance differs between Max 5x and Max 20x. Instead, they linked a Help Center article that I find ambiguous on this point. I don't know whether support has access to the information needed to answer it, but I still think Anthropic needs to explain the difference clearly.

My first impression is that Claude Code 5.5 uses fewer tokens for my workload than the version I was using before. That's welcome news: if it holds up beyond this initial impression, it could ease the practical impact of the weekly limit. It would still leave the question of how the Max 5x and Max 20x allowances are calculated unanswered.

A brief update on my support experience: I eventually received a reply. Support took steps to help with my individual situation, which I appreciate. They also appear to be handling a heavy workload.

could you elaborate on what they offered?

could you elaborate on what they offered?

@adrianipopescu They refunded my monthly subscription fee and cancelled my plan. They didn’t answer my questions about how the weekly allowance differs between Max 5x and Max 20x, or what "20x" means for the weekly limit.

I think I found a likely cause of the Max 5x → 20x quota issue.

It appears that when upgrading the Claude plan, the new subscription tier may not be immediately synchronized with an already-authenticated Claude Code session.

In my case, Claude.ai clearly showed that my account was on Max 20x, but when I inspected the local Claude Code authentication state using:

claude auth status

and:

$raw = Get-Content "$HOME\.claude\.credentials.json" -Raw
if ($raw -match 'default_claude_max_(5x|20x)') { $Matches[0] } else { 'tier not found' }

the credential still reported:

default_claude_max_5x

So there was a clear mismatch:

Claude.ai subscription: Max 20x
Claude Code credential: default_claude_max_5x

I started investigating because, like several other users, my weekly usage was increasing far faster than expected after upgrading.

In my case, I upgraded from Max 5x to Max 20x while my 5x weekly usage was around 78%. After the upgrade, the usage meter reset to 0%, but it reached 36% again after only a few hours of Claude Code usage.

This suggests that the existing Claude Code authentication session may retain the previous Max 5x rate-limit tier after a plan upgrade instead of immediately refreshing to Max 20x.

I cannot confirm from the client side whether this mismatch directly caused all of the abnormal quota consumption, because the actual server-side metering is not visible to users.

However, the mismatch itself is reproducible and clearly visible in the local credentials, so Anthropic should investigate whether usage during this period was being metered against the wrong entitlement.

If you recently upgraded from Max 5x to Max 20x and your quota seems to be draining unusually fast, I recommend checking your local rate-limit tier as well.

Unfortunately, Anthropic Support did not identify this issue for me and provided no meaningful technical investigation.