Opus 4.8: false '1M context credits required' on standard-context session after /clear

[sstraus]

Preflight Checklist

• I have searched existing issues and found related but not identical reports ([BUG] Sonnet 4.6 blocked by false "usage credits required" error #61692, Dispatch feature ignores CLAUDE_CODE_DISABLE_1M_CONTEXT — "Usage credits required for 1M context" blocks background agents #64534)
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

Opus 4.6 (and 4.8) immediately throws "Usage credits required for 1M context" on a fresh session — including right after /clear. The session is NOT using 1M context explicitly. The model was selected via the standard model picker, not the [1m] variant.

Additionally, enabling usage credits at claude.ai/settings/usage (with $0 limit, as suggested by community workarounds in #61692) does NOT resolve the issue. The error persists even after enabling credits and returning to the session.

Error Message

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

Steps to Reproduce

1. Start Claude Code (CLI or desktop)
2. Select Opus 4.6 or 4.8 via /model
3. Run /clear to start fresh
4. Run any skill/command that triggers an LLM call (e.g. a plugin skill)
5. Error thrown immediately

Expected Behavior

Opus 4.6/4.8 should work on standard 200K context without requiring usage credits. If credits ARE required for 1M, the model picker should offer a non-1M variant, and enabling credits with $0 limit should satisfy the gate.

Actual Behavior

1. All Opus requests are force-routed to 1M context tier
2. The 1M credit gate blocks the request
3. Enabling usage credits (with $0 limit) does NOT unblock it — the error persists in the current session
4. No session restart hint is given

Workaround

None confirmed for Opus. CLAUDE_CODE_DISABLE_1M_CONTEXT=1 may work but defeats the purpose of using Opus with extended context.

Relationship to existing issues

• [BUG] Sonnet 4.6 blocked by false "usage credits required" error #61692: Same root cause (false 1M credit gate) but that issue focuses on Sonnet 4.6. This confirms Opus 4.6/4.8 is also affected.
• Dispatch feature ignores CLAUDE_CODE_DISABLE_1M_CONTEXT — "Usage credits required for 1M context" blocks background agents #64534: Same error in dispatch/background agents. This confirms it also happens in interactive sessions.

Claude Code Version

2.1.160

Platform

macOS (Darwin 25.5.0)

Claude Model

Opus 4.6 / Opus 4.8

Is this a regression?

Yes — worked in earlier CC versions without requiring usage credits for standard Opus sessions.

[yurukusa]

A few notes from tracking this across the related filings — what you're seeing lines up with a known cross-surface pattern rather than anything specific to your setup.
Root cause. Opus is being force-routed to the 1M-context tier even when you pick the standard (non-[1m]) model entry, and the 1M tier trips the usage-credits gate. The same silent 1M default has been reported on the plain CLI and the VS Code extension (#62199), on Sonnet 4.6 (#61692, which you linked), and in dispatch/background agents (#64534). So "standard picker entry still hits the 1M gate" is the actual bug — and you're right that no clean Opus workaround is documented yet.
On the env var. CLAUDE_CODE_DISABLE_1M_CONTEXT=1 is the intended lever to pin standard 200K, and it's worth stressing that this is not a downgrade of Opus's reasoning — only of the context window you weren't deliberately using. So it should give you exactly the "Opus on standard 200K" behavior you describe as expected, not a lesser model. The caveat: there's an open report (#63479) that this env var is itself silently ignored in some builds. If you set it (via a shell export, not the settings.json env block — the env-var path is honored more reliably than the settings path) and the gate still fires, that points at #63479 rather than anything on your end.
On the $0-credit workaround not helping. The gate is checked at request start, so enabling credits at claude.ai needs a full process restart to take effect in an already-running session — re-entering the same session often isn't enough. A $0 limit may also fail to satisfy a gate that's looking for a positive allowance; setting a small non-zero cap is worth a separate test.
Quick triage signal. Try /model claude-opus-4-7 as a one-off — if 4.7 is not force-routed to 1M while 4.8 is, that narrows it to the 4.8 routing path specifically, which is useful given the regression / area:model labels already on this.
If it helps confirm the force-route, the session JSONL records the model id actually used per request (the [1m] variant shows up there) — happy to point at the exact field.