Opus 1M context on Max plan requires extra usage despite docs saying 'included with subscription'

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/34333
2. https://github.com/anthropics/claude-code/issues/34585
3. https://github.com/anthropics/claude-code/issues/39482

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I changed my usage limit to $1 to test this and had zero change, not even the false positive of the 1M above

My Claude says your issue appears to be similar to issues #39482, #39000, #39107. Please keep updating. I also want to know whether this has been fixed yet.

I have been charged as well. Could you please let me know how I can apply for a refund from you?

I was also charged, even with only having less than 50% weekly usage, and never exceeding my 5-hour session usage limits. I sent proof with screenshots to a human support agent, but it sat all day with no response.

My issue is the same as this.

On the $200 plan and experiencing this issue :(

I can reproduce this. Using /model to select another model just gives Opus, Sonnet and Haiku. Only after using /model opus I can use my subscription again.

+1, adding data on the billing impact and support-response gap since a few commenters above also reported being charged.

Environment

• Claude Code v2.1.92
• Plan: Max 5x

Repro / error
Selecting opus[1m] shows: "Extra usage is required for 1M context · run /extra-usage to enable, or /model to switch to standard context" — despite the March 13 blog post and the March 20 subscriber email explicitly stating 1M context is included on Max/Team/Enterprise with no extra usage required.

Billing impact

• On upgrading to Max 5x, my weekly usage meter jumped from 8% → 64% instantly, with zero activity in that session (session meter showed 0%). That alone looks like a phantom accounting event tied to the upgrade, not real consumption.
• Approximately £105 in extra-usage charges have accrued against 1M-context calls that per Anthropic's own communications should be included in the plan.

Support timeline (for anyone tracking how this is being handled)

• Wed Apr 8: raised via support chat. The AI agent (Fin) repeatedly classified the usage jump as "expected behaviour" and did not recognise the underlying bug despite multiple clarifications.
• Apr 8: escalated to a human agent.
• Mon Apr 13 (today): still no human response — 5 days of silence. Subsequent AI replies acknowledge 1M context is included on Max but can't action anything, and one reply asserted refund ineligibility citing an unrelated prior refund, while simultaneously confirming the charges shouldn't have been levied.

Support conversation ID: 215473836385266 (for any Anthropic staff who can cross-link this to the open ticket).

Related: #40223 (closed as dup of #34246), #34790.

Update — still broken after upgrading to Max 20x
Following up from my comment yesterday. Upgraded from Max 5x → Max 20x today to try to work around this. Still rate-limited at 0% usage. Total spend now exceeds £300 across plan upgrades and erroneous extra-usage charges.
/bug report submitted — Feedback ID: ec3904d8-ac0a-45a3-99e2-ab47b56a4281
Error logs confirm repeated 429 rate_limit_error responses ("This request would exceed your account's rate limit") on a brand new Max 20x subscription with zero usage. The rate limit response is also returned as plain text where JSON is expected, causing a secondary SyntaxError.
This is now 6 days with no human support response (conversation ID: 215473836385266). The upgrade to a higher plan did not resolve the underlying issue — the account-level flags appear to be stuck from the previous plan tier, as described in #47019.

Was having the same error and I just increased the Monthly spend limit above the actual "spent" limit and it started working again.

Was having the same error and I just increased the Monthly spend limit above the actual "spent" limit and it started working again.

@kkayhan thansk, it works！

+1 — hitting the same issue on Max plan with Opus 4.7 in the VSCode extension.

Environment

• Plan: Claude Max
• Model: claude-opus-4-7
• Client: Claude Code VSCode extension
• OS: Windows 11 Home 10.0.26200

Observed

/context reports 200k token window despite being on Max. Per the model config docs, Opus 1M is "Included with subscription" on Max — but my sessions are capped at 200k.

• Ran /extra-usage → opened billing settings page (shouldn't be needed per docs)
• Logged out and back in → still 200k
• /context output confirms: **Tokens:** 78.2k / 200k (39%)

This matches OP's description exactly — Max users being pushed toward extra usage for a feature documented as included. Still reproducing as of 2026-04-16 on Opus 4.7.

+1 cannot use Opus 1m context - tried log out log in again, tried adding some extra usage - not even that worked.

Also, since this bug, it says my usage is at 100% after like not even a whole prompt. Possible a single compaction. Basically totally broken for me right now. (My work account works, which uses Teams (not Max/Pro)).

I've been using the 1M context for a few days without issues on Max 20x, with extra-usage turned off in my claude settings. For some reason today it started complaining about requiring extra-usage. My usage limits are all at 25% or lower, except Claude Design which sits at 88%.

Had same bug - fortunately got extra $ from Antropic but I'm on x5 and was charged.

Same issue here. Max 20x plan ($200/mo), both on claude.ai web interface and Claude Code.

Financial impact: I was incorrectly charged R$ 591.81 (~USD 105) in extra usage for 1M context that is explicitly documented as included in the Max plan — confirmed by Anthropic's own email (March 20, 2026) and the official blog post.

I opened support ticket #215474025706140 months ago requesting a refund. No human response so far — only the Fin AI agent. No refund has been issued.

Confirming @kkayhan's workaround: I was completely blocked from using 1M context because my monthly extra usage spend limit (R$ 20) had been exceeded. I increased it and it unblocked access. The extra usage balance appears stable after the change — it does not seem to be actively consuming credits. But this is the core problem: Max plan users are forced to have extra usage enabled with available balance just to access a feature that is already included in their subscription. If your spend limit is reached or extra usage is disabled, you're locked out of 1M context entirely.

This means we must maintain extra usage credits and a sufficient spending limit as a prerequisite to use what we already paid for. Users who responsibly keep extra usage disabled or set low limits to prevent surprise charges are punished the most.

Environment:

• Plan: Max 20x ($200/mo)
• Platform: Windows
• Model: Opus 4.7 1M
• Financial impact: R$ 591.81 (~USD 105) incorrectly billed as extra usage
• Support ticket: #215474025706140 (no human response, no refund issued)

Also affected on Max plan, Claude Code v2.1.133 (latest, May 7 2026), macOS.

Confirmed the same behavior: Sonnet 4.6 has no 1M option in /model at all, and Opus 4.6 1M either requires extra usage or doesn't actually activate the extended window. The tengu_hawthorn_window flag staying at 200K regardless of model selection explains why — the context window never actually changes server-side even when the picker accepts the model.

This is particularly frustrating given that the docs explicitly say 1M context is included with Max. Cross-referencing related issues I've also commented on: #34773 (Sonnet 1M missing from picker entirely), #28927 (silent billing change in v2.1.51 with JSONL proof). This looks like a systemic billing/entitlement problem, not isolated incidents.

Adding a fresh data point on this — and a v2.1.148 wrinkle that nobody on the thread has pinned down yet.

Environment:

• Plan: Max 5x (downgraded from Max 20x on 2026-05-23)
• Claude Code: in-place upgrade v2.1.131 → v2.1.148 on 2026-05-25
• Extra-usage: enabled, balance $22.40 (unchanged after the workaround)

Timeline (verified from per-session jsonl cache_read peaks):

1. Pre-05-23 on Max 20x — bare claude-opus-4-7 auto-upgraded to 1M as documented. Long-running sessions consistently saw cache_read above 800K (one peaked at 997K).
2. 05-23 downgrade to Max 5x — server-side entitlement flipped, but already-running CC processes kept hitting 1M ceilings (cache_read peaks of 924K observed two days later on a session that had been running through the downgrade).
3. First CC process restart after the in-place v2.1.131 → v2.1.148 binary update — this is the actual trigger. New process re-fetched account entitlement at startup. Max 5x doesn't auto-upgrade. Default claude-opus-4-7 resolved to 200k. Subsequent cache_read peaks dropped to ~165K — auto-compact threshold for the 200k tier. We saw this fire on two independent sessions, both with cache_read dropping to ~165K within 3 minutes of the jsonl version field flipping from 2.1.131 → 2.1.148.
4. Settings.json fix — added "claude-opus-4-7[1m]" to both "model" and env.ANTHROPIC_MODEL. 1M restored on next launch. Extra-usage balance unchanged → no billing impact on our account.

What this adds to the thread:

• The first CC process restart after a v2.1.131 → v2.1.148 in-place binary update is a fresh trigger for the latent Max-5x entitlement gap. Long-running CC processes keep working at 1M even after a plan downgrade — the 1M state is loaded once at process start and held across many sessions on the same PID. The drop manifests on the next clean restart of the CC process under 2.1.148, which re-fetches account entitlement. Worth checking against any reports here where the symptom appeared "out of nowhere" — it may correlate with whenever the user next restarted CC after the auto-update, not with the auto-update itself.
• Confirms the gate is non-deterministic across Max 5x accounts. Per @andersonaggie05 (OP), [1m] is "blocked OR billed as extra usage." On our account today: [1m] works AND is not billed. Same plan tier, opposite behavior. Consistent with @kyle3728 #34958 ("works on one machine, not another, same account") and @jardaon's framing — having extra-usage enabled with available headroom appears to be the load-bearing precondition, not whether usage is actually consumed.
• The settings.json workaround is stable across session restarts. \--model\ flag and \/model\ work too but session-only; \model\ in settings.json plus \env.ANTHROPIC_MODEL\ covers both the default-launch path and the env-resolver path consistently. Quote the brackets in shell (\claude --model "claude-opus-4-7[1m]"\) — \[\ is a glob char in bash/zsh and unquoted invocations fail differently than the workaround docs imply.

Documentation discrepancy this thread has been flagging for two months:

The Model configuration docs say On Max, Team, and Enterprise plans, Opus is automatically upgraded to 1M context with no additional configuration — undifferentiated between Max 5x and Max 20x. The docs DO subdivide Teams (Standard vs Premium) when the entitlement differs by sub-tier, so the absence of a Max-tier subdivision reads as deliberate. Either the docs are correct and the implementation is broken on Max 5x (most reports here), or there's an undocumented Max-5x-vs-20x carve-out for 1M that should be reflected in the docs.

— AI Team Lead

One CLI-vs-VS-Code-extension wrinkle worth surfacing here, since our recommendation above didn't differentiate by surface:

@gdb-mtx on #50083 reported yesterday (2026-05-26) that the VS Code extension actively strips [1m] from the model field in ~/.claude/settings.json on every launch, via an unpinOpus47LaunchEffort migration. So the settings.json model field approach we recommended is stable on the CLI (we've been running it for 24+ hours unchanged on a Max 5x account) but gets reset every restart on the VS Code extension.

For VS Code extension users on Max 5x, the workaround that actually holds is the env-var approach in the same settings.json file:

\\\json
{
"env": {
"DISABLE_COMPACT": "1",
"CLAUDE_CODE_MAX_CONTEXT_TOKENS": "1000000"
}
}
\\\

The migration only rewrites the model field, not the env block. The 1M context activates via the CLAUDE_CODE_MAX_CONTEXT_TOKENS env-var path even with model reset to claude-opus-4-6. Verified by @gdb-mtx via /context showing /1m after the migration runs.

Quick triage for which fix to use:

| Surface | Fix |
|---|---|
| CLI (claude terminal) | "model": "claude-opus-4-7[1m]" + env.ANTHROPIC_MODEL: "claude-opus-4-7[1m]" |
| VS Code extension | env.DISABLE_COMPACT=1 + env.CLAUDE_CODE_MAX_CONTEXT_TOKENS=1000000 |

— AI Team Lead

Same issue here. Max 20x plan ($200/mo), both on claude.ai web interface and Claude Code.

Financial impact: ~R$ 830 (~USD 150) across two incidents

First incident: R$ 591.81 incorrectly billed as extra usage for 1M context that is explicitly documented as included in the Max plan — confirmed by Anthropic's own email (March 20, 2026) and the official blog post. I opened support ticket #215474025706140. No human response. No refund.

Second incident (June 1, 2026): Confirming @kkayhan's workaround, I increased my monthly extra usage spend limit from R$ 20 to R$ 30 to unblock 1M context access. It appeared stable initially. However, the system then consumed ~R$ 238 from my extra usage credits in a single day, despite having plan tokens available (47% weekly limit remaining, only 6% session usage). My balance dropped from R$ 682.28 to R$ 410.34. I immediately disabled extra usage and auto-recharge.

The core problem

Max plan users are forced to have extra usage enabled with available balance just to access 1M context — a feature already included in their subscription. But it gets worse: the system doesn't just gate access behind extra usage, it actively charges for it, even with plan tokens available.

This means:

• If you disable extra usage → you're locked out of 1M context
• If you enable extra usage → your credits get consumed for a feature you already paid for
• If you set a low spend limit to protect yourself → you get blocked once it's reached
• Users who responsibly limit extra usage to prevent surprise charges are punished the most

Support is a dead end

I contacted support today. Anthropic's AI agent (Fin) confirmed in writing that:

1. This is a "technical billing error that needs review"
2. It "cannot process refunds or escalate" the case
3. The standard refund flow is "designed for subscription cancellations, not extra usage billing errors"
4. My situation "falls outside the standard scenarios" it can address

So Anthropic's own support agent acknowledges the billing error but has no mechanism to fix it. There is currently no path to resolution for affected Max plan users.

Environment

• Plan: Max 20x ($200/mo)
• Platform: Windows
• Model: Opus 4.7 1M
• Total financial impact: ~R$ 830 (~USD 150) incorrectly billed as extra usage
• Support ticket: #215474025706140 (no human response, no refund)

@jardaon — the "47% weekly remaining + 6% session usage + extra-usage credits consumed anyway" pattern matches the auth-mode-classification failure mode documented on #41930 and #45572: session-level auth context can shift such that the API-key billing path bills against extra-usage even when subscriber auth was in use for the session. The 6% session-usage data point is particularly clean evidence against the "you must have hit your plan limit" framing.

Sorry you got hit twice. The Fin transcript — "technical billing error that needs review" with no escalation path — is worth keeping for the record either way.

— AI Team Lead

+1 with macOS repro details

Confirming on Max subscription with identical gate behavior.

Environment:

• Plan: Max
• OS: macOS (Darwin 25.4.0)
• Claude Code CLI, latest version

Repro:

1. On Max subscription, run /model and select Opus with [1m] context variant
2. Submit any prompt (tested with skill invocation and simple prompts)
3. Consistent failure: API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to standard context

Specific observation:

• Sonnet 4.6 [1m] works fine on the same account with no usage credits enabled
• This is the inverse of documented Max-plan behavior (Opus 1M should be included, Sonnet 1M should require extra usage)

Workaround attempted:

• Restarting Claude Code does not fix the gate
• Re-selecting model via /model does not fix the gate

The gate appears to be incorrectly treating Opus 1M as a paid add-on on Max plans, despite docs stating it should be automatic.