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

[Rene3481]

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?

Claude Code blocks all requests with "API Error: Usage credits required for 1M context" even though Pro plan usage is only 17% of weekly limit.

The error fires before model selection processes, making --model flag and CLAUDE_CODE_DISABLE_1M_CONTEXT workarounds ineffective.

Versions tested: 2.1.104 (WinGet), 2.1.6 (npm), 2.0.0 (npm) — all produce the same error.

To use Claude Code at all, I was forced to purchase additional usage credits (R$ 15.00 / ~$3 USD). Even after purchasing, Claude Code continued showing "credits exhausted" errors despite R$ 17.26 remaining balance confirmed in claude.ai/settings/usage. The system consumed credits rapidly during normal coding sessions without any long-context usage requested by the user.

This is unacceptable: Pro plan users are being forced to purchase extra credits due to a bug, and even after paying, the tool remains unreliable.

What Should Happen?

Claude Code should work normally within Pro plan limits without requiring additional usage credits. The 1M context window should not be forced on users who never requested it. When usage credits are purchased, the remaining balance should be fully accessible without interruption.

Error Messages/Logs

API Error: Usage credits required for 1M context · turn on usage credits at claude.ai/settings/usage, or use --model to switch to standard context

Steps to Reproduce

1. Have an active Pro plan (weekly usage at 17%)
2. Open Claude Code in VS Code on Windows 11
3. Type any message or command
4. Error appears immediately: "API Error: Usage credits required for 1M context"
5. Tried workarounds: --model claude-sonnet-4-6, CLAUDE_CODE_DISABLE_1M_CONTEXT=1, downgrade to 2.1.6 and 2.0.0 — all fail
6. Purchased R$15.00 in usage credits
7. Error persists even with R$17.26 balance confirmed in claude.ai/settings/usage

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.6

Claude Code Version

2.0.0 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

User was forced to purchase R$15.00 in usage credits due to this bug. Even after purchase, Claude Code continued blocking with the same error despite R$17.26 confirmed balance in claude.ai/settings/usage. The error affects all versions tested (2.1.104, 2.1.6, 2.0.0) and fires immediately on any command, before any model processing occurs. Related issues: #62063, #62199, #63060, #63634.

[github-actions]

Found 3 possible duplicate issues:

1. [Bug] Usage credits required for 1M context on Max 5x plan — standard model selected, Cowork + Claude Code #64970
2. [BUG] Claude Code defaults to 1M context on fresh session with no workaround on Pro plan #62063
3. [BUG] Sonnet 4.6 blocked by false "usage credits required" error #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

[Rene3481]

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

[cnighswonger]

@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

[loglux]

The script prune-session.sh helps to deal with it and carry on:
#63634 (comment)

[yurukusa]

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):

   setx CLAUDE_CODE_DISABLE_1M_CONTEXT 1

2. 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.

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

   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).

[salo2017]

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.

[loglux]

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