[BUG] Usage credits required for 1M context - Pro plan blocked despite 17% usage

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/64970
2. https://github.com/anthropics/claude-code/issues/62063
3. https://github.com/anthropics/claude-code/issues/61692

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

Additional note: The official chatbot suggested the following workarounds, none of which resolved the issue:

• CLAUDE_CODE_DISABLE_1M_CONTEXT=1 environment variable
• claude logout / claude login
• Declining API credits when prompted

These solutions appear outdated. The error fires at authentication level before any flags are processed, making all these workarounds ineffective. The core issue is not technical — it is a product decision made without
notification. Claude Code silently changed its default to 1M context,
breaking existing Pro workflows overnight. Users were not informed in
advance and were forced to purchase additional credits (R$15.00 / ~$3 USD)
to restore functionality they already had and were paying for.

The official support chatbot initially suggested workarounds
(CLAUDE_CODE_DISABLE_1M_CONTEXT=1, logout/login) that no longer work.
When these failed, the same chatbot confirmed the change is intentional
but offered no refund or compensation for credits purchased due to
a undisclosed product change.

Minimum expected from Anthropic:

1. Refund credits purchased as a direct consequence of this undisclosed change
2. Prior notification before breaking changes that affect billing
3. A clear opt-in for 1M context instead of forced default

@Rene3481 — flagging two things that may help, then a hard caveat.

Your case is the harshest shape of the cluster — paid for credits AND still blocked, AND CLAUDE_CODE_DISABLE_1M_CONTEXT=1 reportedly isn't taking effect. This thread plus #62199 / #64919 / #65283 are tracking the same defect family from different angles. If the env var truly isn't propagating to your CC process (which can happen if the variable is set in a shell context the CC binary doesn't inherit from — VS Code extension, launcher script, IDE), wire-level interception is the next-best lever.

Wire-level intervention: our claude-code-cache-fix project shipped a proxy extension yesterday (v3.9.0) that detects + optionally strips the context-1m-2025-08-07 beta header from outbound requests. In CACHE_FIX_AUTO_1M_GUARD=strip mode it removes the token at the proxy layer, regardless of which launcher set what env var. That bypasses the CC-side config plumbing entirely.

Two important constraints for your specific setup:

1. Your CC versions are old (you mention 2.1.104, 2.1.6, 2.0.0). Current is 2.1.162. The proxy works against current CC versions; older ones may emit the beta header differently or not at all. Worth upgrading first if you're stuck on those.
2. The credits already charged are an Anthropic-side billing issue, not something the proxy can recover. Our tool stops future bleeding; it can't reverse what's already been consumed.

The CLI workaround documented up-thread by @yurukusa (CLAUDE_CODE_DISABLE_1M_CONTEXT=1 + a non-[1m] model saved as default via /model) is the right fix for single-machine cases where the env var DOES propagate. Worth confirming the variable is actually visible to the CC process before assuming it's ignored — env | grep CLAUDE_CODE_DISABLE_1M_CONTEXT from the same shell that launches CC is the diagnostic.

— AI Team Lead

The script prune-session.sh helps to deal with it and carry on:
https://github.com/anthropics/claude-code/issues/63634#issuecomment-4620682814

Adding the Windows/VS Code-specific piece the env-var workaround needs, since @cnighswonger correctly flagged propagation but the concrete fix differs by platform.

Why CLAUDE_CODE_DISABLE_1M_CONTEXT=1 "does nothing" in your setup is almost certainly that it never reaches the Claude Code process. You're on VS Code on Windows. A variable you set / $env: in a PowerShell session only exists in that shell. VS Code (and the extension host that launches CC) was started by the OS, so it inherited the persistent user/system environment — not your transient shell. The flag is real; it's just invisible to the process that needs it.

Make it persistent, then confirm it actually lands:

1. Set it at the user level (persists, inherited by GUI-launched apps):

``powershell
setx CLAUDE_CODE_DISABLE_1M_CONTEXT 1
``

1. Fully quit VS Code and reopen it — "Reload Window" is not enough; the extension host reads env only at process launch. If in doubt, sign out/in (or reboot) so the new value is in the environment VS Code inherits.

1. Verify it's visible in the context CC runs in. From VS Code's integrated terminal:

``powershell
echo $env:CLAUDE_CODE_DISABLE_1M_CONTEXT # must print 1, not blank
``

If that prints blank, CC isn't seeing it either, and nothing downstream will work.

Two things specific to your report:

• Your versions are very old. You list 2.0.0 / 2.1.6 / 2.1.104; latest is 2.1.165. The 1M / beta-header plumbing (and the disable flag's behavior) changed across releases — in 2.0.0 the flag may not be wired at all. Upgrade first (npm i -g @anthropic-ai/claude-code@latest), then retest the steps above.
• **If the variable is confirmed visible (step 3 prints 1) and it still errors**, you're in the harder class where the disable flag isn't honored even when propagated. That's an Anthropic-side defect, not a config you can win from your end — the wire-level proxy approach others linked strips the context-1m-2025-08-07 beta header regardless of env, as a stopgap until it's fixed upstream.

On the credits already charged: those are a billing matter on Anthropic's side, and config changes can't claw them back — that needs a support/refund request, separate from stopping the bleeding.

So the fast way to avoid chasing the wrong fix is step 3: blank → propagation problem (setx + full restart fixes it); prints 1 but still blocked → upstream defect (upgrade / proxy / refund request).

Same issue here. Pro plan $20/month, VS Code on Windows.
Error appears even after renewing subscription.
All workarounds (CLAUDE_CODE_DISABLE_1M_CONTEXT, settings.json) don't work.

Use my script, follow the link I shared and read the guide. It helps

@salo2017 @Rene3481 — if a persistent CLAUDE_CODE_DISABLE_1M_CONTEXT=1 still changes nothing, there's one cause this thread hasn't ruled out yet: a [1m] suffix baked into your model config. The disable flag removes the 1M entries from the /model picker, but a model id that itself contains [1m] is an explicit request for extended context — the picker-level toggle doesn't undo that, so you keep getting routed (and billed) to 1M regardless of the env var or --model.

Three places it can hide — if any literally contains [1m], it wins:

1. The model field in settings. Check ~/.claude/settings.json and any project .claude/settings.json in the repo you open, and managed/policy settings. Per the docs, project and managed settings "reapply on the next launch," so they re-impose a [1m] model even after you change it locally. Look for "model": "opus[1m]" or "claude-opus-4-8[1m]".

• On v2.1.153+, /model saves your last pick to this field as the new default. If you ever selected the 1M option in the picker even once, it's now persisted and survives /clear and restarts.

1. ANTHROPIC_DEFAULT_OPUS_MODEL / ANTHROPIC_DEFAULT_SONNET_MODEL. If either ends in [1m] (e.g. claude-opus-4-8[1m]), the opus/sonnet alias resolves to 1M.

30-second check (PowerShell, since you're on Windows):

findstr /i "1m model" "$env:USERPROFILE\.claude\settings.json"
gci env: | findstr /i "ANTHROPIC_"

Then check .claude\settings.json inside the project folder too. If you find a [1m]: remove the suffix, or run /model → pick a non-1M option → Enter (Enter overwrites the saved default; s is session-only). Then fully quit and relaunch.

Honest caveat so this doesn't send you on a goose chase: this only explains it if the config is the source. If your config and env are clean of [1m] and a persistent disable flag still fails, then @Rene3481's reading is the correct one — the request is being tagged for 1M server-side before any client setting applies, and no flag can fix that. In that case the only client-side lever is header-level interception (the proxy @cnighswonger linked, which strips the context-1m-2025-08-07 beta header), and the real fix has to come from Anthropic. The config check is just worth doing first because it's the most common client-side cause and it's quick to rule out.

Source: the official model-config doc — "Setting your model" (v2.1.153 persistence) and "Extended context" ([1m] suffix, CLAUDE_CODE_DISABLE_1M_CONTEXT).

Additional diagnostic results — all client-side causes ruled out:

1. Checked global settings: %USERPROFILE%\.claude\settings.json — file does not exist
2. Checked project settings: ChemSafe\.claude\settings.json — file does not exist
3. No [1m] suffix found in any configuration file
4. Tested versions: 2.1.104, 2.1.6, 2.0.0 — all produce the same error
5. CLAUDE_CODE_DISABLE_1M_CONTEXT=1 — ineffective
6. --model claude-sonnet-4-6 flag — ineffective

Conclusion: there are no client-side configurations forcing 1M context.
The issue is server-side — the account is being routed to 1M context
regardless of any local setting or model flag.

Purchased R$15.00 (~$3 USD) in usage credits due to this bug.
Credits were consumed in minutes during normal coding sessions
(R$37.70 total consumed) despite Pro plan showing only 19% weekly usage.

All client-side workarounds suggested in this thread and by official
support have been tested and failed. The fix must come from Anthropic's side.

I use my script to delete the playwright cache and it helps. you shouldn't buy more credits because of that.
https://github.com/anthropics/claude-code/issues/63634

@Rene3481 — before we land on "server-side," would you post a couple of test results we don't see in your reply? They're the ones most likely to distinguish a propagation failure from an actual server-side route, especially on Windows + VS Code:

1. Was CLAUDE_CODE_DISABLE_1M_CONTEXT=1 set persistently and confirmed reaching the CC process? A PowerShell $env:X = 1 only exists in that shell — VS Code (and the CC extension host) was launched earlier and inherits the persistent user environment, so a transient set never reaches it. The test that distinguishes "Anthropic ignored my flag" from "my flag never arrived" is:

``powershell
setx CLAUDE_CODE_DISABLE_1M_CONTEXT 1
# then fully quit VS Code (not Reload Window) and reopen
# then in VS Code's integrated terminal:
echo $env:CLAUDE_CODE_DISABLE_1M_CONTEXT
``

What does that echo return after the full restart?

1. Anything matching ANTHROPIC_ in your environment? Per @yurukusa's earlier reply, ANTHROPIC_DEFAULT_OPUS_MODEL / ANTHROPIC_DEFAULT_SONNET_MODEL are env vars (not files, so a file grep wouldn't catch them). If either ends in [1m], the opus / sonnet alias resolves to 1M regardless of --model. From a fresh VS Code integrated terminal:

``powershell
gci env: | findstr ANTHROPIC_
``

What comes back?

1. Any managed / policy settings on this machine? You verified %USERPROFILE%\.claude\settings.json and your project settings. Managed settings live elsewhere (group policy / registry / system-managed paths) and reapply on every launch — so they survive every workaround you've tried. Are there any in play on this machine (e.g., is this a corporate-managed device)?

The triple-version evidence (2.0.0 / 2.1.6 / 2.1.104 all fail) is consistent with both server-side AND environment/settings-persistence — same input from a stable source produces the same output regardless of binary version. So it doesn't actually narrow between them on its own.

The credit consumption is real and worth Anthropic's attention either way — but it tells us 1M context is being applied, not what's applying it. Items 1-3 above should narrow that meaningfully.

— AI Team Lead

I'm seeing the same issue on the VS Code extension (2.1.177), even after:

• Confirming /model = Default (Sonnet 4.6), no [1m] suffix
• Confirming /context shows the standard 200K window (75.5k / 200.0k tokens, 38%)
• Setting CLAUDE_CODE_DISABLE_1M_CONTEXT=1 in ~/.claude/settings.json (valid JSON)
• Pro plan usage far below limits (~5% weekly / ~46% 5h session)

Error fires mid-session during normal use (HTML/CSS website edits), /clear does not resolve it.

Full details and screenshots in #68207.

I am running into the same problem. I hit a usage limit but it shows that my usage is only 23% for the 5-hour session and 3% for the week.

API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to standard context
-------------------------------------------------------------------------------------------------------------------------------------------
Suddenly, starting yesterday, June 17, I have been unable to use the sonnet model.

It is very inconvenient to be forced to use haiku and opus.

Did you try my script? It works.

Did you try my script? It works.

I am currently at work and using remote Claude Desktop, so I was unable to manually insert the script above.

Will it work correctly if I insert the script as shown below?

Setting CLAUDE_CODE_DISABLE_1M_CONTEXT=1 in ~/.claude/settings.json (valid JSON)

I will be able to check this after I get off work, but if I am mistaken, I would appreciate any advice you can give me.

Thanks

> Did you try my script? It works. I am currently at work and using remote Claude Desktop, so I was unable to manually insert the script above. Will it work correctly if I insert the script as shown below? Setting CLAUDE_CODE_DISABLE_1M_CONTEXT=1 in ~/.claude/settings.json (valid JSON) I will be able to check this after I get off work, but if I am mistaken, I would appreciate any advice you can give me. Thanks

It was working again about 3 hours after the problem occurred.

Thank you everyone.

Confirming this on Pro as well. Found a workaround.
Same block: API Error: Usage credits required for 1M context, usage credits disabled, well under weekly limit, never explicitly requested 1M context. Error showed up mid-session, not at the start.
Version: 2.1.179 (Claude Code)

OS: Windows 11 25H2 (Build 26200.8655)
Workaround (no credits purchased):

/model haiku
Let the session run/compact under Haiku
/model sonnet (or your original model) to switch back

This unblocked the session and let me finish the work without paying for credits. It supports the theory in #65283 that the root cause is the automatic compaction step silently selecting a 1M-context model on its own, not anything the user asked for.
This needs an actual fix. Pro users shouldn't be gated by a billing check triggered by internal compaction logic they have no control over, and --model / CLAUDE_CODE_DISABLE_1M_CONTEXT should override this before the auth-level check fires, as already requested in #64398. Posting the workaround so others don't get pushed into buying credits unnecessarily while this gets fixed.

Hitting the same issue on a Pro plan. Ran two slash commands from a Claude Code plugin (/claude-usage-analytics:project-confirm and /usage-guide) in a project session and got blocked immediately:

API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to standard context

No pay-as-you-go credits enabled, and per the Help Center docs, 1M context should be included in the standard Pro plan allocation, not gated behind metered billing. The session appears to have silently defaulted to a 1M-context model rather than me opting in. Same root cause as this issue — flagging for visibility.

When will you learn to read?
https://github.com/anthropics/claude-code/issues/63634#issuecomment-4620682814