Claude Code changed default model to 1M context without notifying Pro users

Adding a data point from the other side of this same v2.1.148 default-model change.

We hit a matched-pair regression on Max 5x: bare claude-opus-4-7 resolved to 200k instead of the documented "automatically upgraded to 1M context with no additional configuration" — full timeline at #39841 (the longstanding Max-5x 1M discrepancy thread). Same v2.1.131 → v2.1.148 trigger, same first-CC-process-restart-after-the-binary-update pattern, but the symptom on Pro vs Max is asymmetric in an important way:

• Max users: silent loss of a capability (1M context dropped to 200k). Workflow degrades, no charge.
• Pro users (this thread): silent introduction of a chargeable feature into the default path. Workflow blocks unless extra-usage credits are enabled.

The financial asymmetry is what makes the Pro side of this worse, not better. A Max user can recover their old behavior by adding [1m] to their model identifier and pay nothing extra. A Pro user has to either accept a smaller-context model than the new default points to, or opt into a billing surface they previously had no need for.

Immediate workaround for anyone landing here: explicitly pin a 200k-tier model in your settings to bypass the changed default. Either approach works:

\\\jsonc
// in ~/.claude/settings.json
{
"model": "claude-sonnet-4-6"
}
\\\

\\\`bash

or as an env var

export ANTHROPIC_MODEL=claude-sonnet-4-6
\\\`

\\\`bash

or per-launch

claude --model claude-sonnet-4-6
\\\`

This restores the documented Pro default (per code.claude.com/docs/en/model-config#default-model-setting: Pro, Team Standard, Enterprise, and Anthropic API: defaults to Sonnet 4.6). It doesn't fix the underlying default-resolution regression — but it stops the bleeding while Anthropic sorts it out.

On the OP's three requests: all three are reasonable for a release that introduces a chargeable default. The advance-notification ask is the most actionable — the precedent already exists in the docs (see the April 23, 2026 migration note for Enterprise/API users in the model-config docs). The same notification courtesy should extend to plan tiers where the change shifts users from $0 to extra-usage billing.

— AI Team Lead

I just hit the same bug where the 1M context started silently using my additional usage credits until I hit my configured monthly spend limit. I would also like to suggest a real-time indicator whenever additional paid credits are being used. I'm primarily using the Claude Code for VS code extension, and an indicator in the same place the "You've hit your usage limit" message shows up would be useful.

estou começando a usar a IA agora, e me deparei com o erro

Algo deu errado
Tente enviar sua mensagem novamente. Se continuar acontecendo, compartilhe um feedback para que possamos investigar.

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
Você pode reiniciar a conversa a partir de uma mensagem anterior.

mesmo reiniciando a conversa o erro persiste . como posso resolver ?

+1, hitting this too and it's frustrating. The default model was silently switched to a 1M-context variant that requires usage credits — no notification, no email, no in-app warning. You just open a new session and hit "Usage credits required for 1M context." It's especially confusing that Sonnet with 1M requires credits even on paid plans. Please make standard 200K context the default and make 1M an explicit opt-in rather than a silent switch.

got the same problem now. work with sonnet 4.6 til now. I never changed to use this 1M... just use my 5h/wekk limits - worked 4 me till now.
Claude Chat: set environment variable: Name: CLAUDE_CODE_DISABLE_1M_CONTEXT / Wert: 1
...and in VSCode: in user settings: "claudeCode.environmentVariables": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
...doesn´t work 4 me. issue still ongoing...

Im hitting this now and auto compacting results to an API error and will not proceed to compacting. Also it says 100% context used always in the terminal

I ran into this last night. Windows 11, using PowerShell. Same issue as everyone else.

I turned off autoUpdates and reverted to 2.1.149 and that fixed it.

settings.json
{
"autoUpdatesChannel": "latest",
"theme": "dark",
"autoUpdates": false,
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}

revert to 2.1.149 -

npm install -g @anthropic-ai/claude-code@2.1.149

Then closed all windows, opened them up and I was able to work again. YMMV.

i started an new conversation - like discribed in https://github.com/anthropics/claude-code/issues/63702
...and it works. seems realy depending to the size of the conversation - claude seems unable to compress the conversation and requests unchangeable the 1M-context.
i try to revert to 2.1.249 later to reuse the old conversation for testing

Pulling together a few threads that have surfaced on this issue and the related ones over the last 48 hours, since they're starting to look like one cluster:

1. The specific CLAUDE_CODE_DISABLE_1M_CONTEXT=1 override does not appear to be respected by the VS Code sidebar in these Pro reports. @DieWaldfee on this thread (2026-05-30) and @pandre01 on the newly-filed #63702 both report the variable correctly set in their environment but the sidebar extension still hits "Usage credits required for 1M context." For this specific Pro / DISABLE_1M_CONTEXT case, terminal launches respect the override; the sidebar does not. (Other env-var-based workarounds in this area have worked in VS Code before — see #50083 — so this is narrower than "env vars don't reach the extension.")

2. Conversation size appears to be a trigger axis on the sidebar failure. pandre01's second comment on #63702 (and DieWaldfee here) report that the bug fires reliably on existing large conversations but does NOT fire on fresh ones in the same project. Separately, ScarletThe4EyedCuda reports that downgrading to 2.1.149 + autoUpdates: false + the env var works for them — but that's evidence the downgrade helps, not specifically that 2.1.149 stayed below a size threshold. Two separable axes (conversation size, version) both look implicated.

3. The 1M default is being re-asserted on the VS Code extension on a different but related surface. Adjacent evidence, not the same bug: on #50083, @gdb-mtx documented that VS Code launches run an unpinOpus47LaunchEffort migration that strips explicit model: "claude-opus-4-6[1m]" pins from ~/.claude/settings.json on every startup. That migration touches the model pin, not the 1M-context env var, but it's the same shape: the VS Code extension treats user-set persistence as fungible and re-resolves on launch in ways the terminal client doesn't.

Practical guidance for anyone hitting this right now, by surface:

• Terminal claude command, Pro/Max: the env block in ~/.claude/settings.json with CLAUDE_CODE_DISABLE_1M_CONTEXT: "1" works. @ScarletThe4EyedCuda's settings example earlier in this thread is correct for terminal use.
• VS Code sidebar extension, Pro: no durable same-surface workaround beyond /new (per pandre01 on #63702). One user reports success by downgrading to 2.1.149 + autoUpdates: false + the env var, which avoids the trigger entirely but freezes you out of subsequent fixes.

Cluster shape, tiered by how confidently they link:

• Strong link (same surface, same symptom, Pro): this issue, #62063, #63702.
• Plausibly related: #63700.
• Adjacent evidence, not proven same bug: #50083 (model-pin migration), #39841 (Max 5x 1M default).

If the VS Code extension is resolving 1M before honoring CLAUDE_CODE_DISABLE_1M_CONTEXT, fixing that order would likely close the biggest Pro / sidebar gap. That's an inference from the symptom pattern, not direct evidence of the extension's resolution logic — but it would be a high-leverage place to look.

— AI Team Lead

The issue is that even with Max, Sonnet is showing a 200k Context window in /context, but can go over that by a few hundredk and then errors saying you are out of usage in one part and that you need to turn on usage in another.

Zero desire for usage for this.

This broke clearly aligned with changes associated with Opus 4.8 rollout

using vscode extension

I'm having the same issue. It wasted all the credit in my account as it hadn't made clear what was going on. It's making claude code unusable.

it turned on yesterday, burnt through my session quota two or three times before i realised what was going on, took me hours to work out what on earth was happening and how to fix. there was no info available at that point i could find. compacted and set the env_var via claude code, opened desktop and it held again till today. it's just burnt through my quota once more; absolutely not happy, absolutely not ok and getting in the way of rented GPU time. The fact that this is 'just rolled out' is pretty s***y. just added:

"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}

to settings, seems to have done something - will know when my quota resurfaces.

I use /clear , then the issue is gone

Solution that worked for me (Windows + VS Code)
After trying everything mentioned in this thread, this combination finally worked:

1. Downgrade to version 2.1.149:

npm install -g @anthropic-ai/claude-code@2.1.149

1. Create/edit Claude's settings.json at C:\Users\YourUser\AppData\Roaming\Claude\settings.json:

json{
"autoUpdates": false,
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}

1. Close VS Code completely and open a new window.

Note: the CLAUDE_CODE_DISABLE_1M_CONTEXT=1 environment variable alone did NOT work, nor did the --model flag. The key was combining the downgrade + settings.json + fresh window.
I have two separate Pro accounts — both were blocked.

Same issue, Pro plan, VS Code extension, workaround CLAUDE_CODE_DISABLE_1M_CONTEXT does not work either. This is REALLY annoying !

For everyone hitting this on the VS Code extension where CLAUDE_CODE_DISABLE_1M_CONTEXT=1 is ignored (@jpdeion @DieWaldfee and others): the most reliable lever I've found is the in-session model switch, which takes effect even when the env var and launch flags don't:

/model claude-opus-4-7

(or any model ID without the [1m] suffix — e.g. claude-sonnet-4-6, claude-haiku-4-5). It switches immediately, no restart, and you can confirm with /status that you're back on a 200K-context variant. This is what actually stopped the drain for me when the env-var route was a no-op in the extension.

Why it drains so fast: a 1M-context variant carries a much larger cached context prefix that gets re-read every turn, and those cache_read / cache_creation input tokens count toward the 5h/weekly limit (and usage credits) — so a session can burn the limit far faster than the visible "work" suggests, which matches the reports above.

Two notes:

• /clear (as @IrishBird mentioned) helps because it drops the accumulated context, but it doesn't change the model variant, so the drain can resume on a long session. /model <non-1m> is the durable fix.
• If a SessionStart heads-up would be useful, there's a free MIT hook that checks $ANTHROPIC_MODEL and warns when you're on a [1m] variant before you start burning: cowork-model-picker-advisor in cc-safe-setup (I just extended it to cover this exact CLI / VS Code case). Entirely optional — the /model switch above is the actual fix.

Hope it saves someone the credits.

`` /model claude-opus-4-7 ``

@yurukusa - This solved it for me - 👏🏻

Workaround that worked for me: Downgrade the VS Code extension to v2.1.144

I was getting the same error on Pro plan — "API Error: Usage credits required for 1M context" — even on fresh sessions with minimal usage. None of the usual fixes worked (editing .claude/settings.json, setting ANTHROPIC_DEFAULT_SONNET_MODEL env var, modifying ~/.claude.json, etc.).

The root cause seems to be that the VS Code extension bundles its own version of Claude Code independently from the CLI, so downgrading the CLI via npm has no effect on the extension.

Steps to fix:

1. Open the Extensions panel in VS Code (Cmd+Shift+X)
2. Find Claude Code for VS Code
3. Click the dropdown arrow next to the Uninstall button
4. Select Install Specific Version
5. Choose 2.1.144 (2 weeks old — before the bug was introduced)
6. After installing, disable Auto Update for the extension to prevent it from upgrading automatically
7. Click Restart Extension

After downgrading, the extension works normally again on Pro plan without requiring Usage Credits.

Hope this helps others while Anthropic works on a fix!

I have also this problem, when i use Claude code with remote-control, even though i have set sonnet 4.6 as default model it always keep changing automatically to opus 4.7 1M during sessions, and of course hitting the:
_API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to standard context_
Model switching does do work, only if the session is restarted....

<img width="1008" height="2244" alt="Image" src="https://github.com/user-attachments/assets/bc58d2e8-42ac-4911-aecd-3f9a76a034f1" />

<img width="1008" height="2244" alt="Image" src="https://github.com/user-attachments/assets/b700136e-8c18-434c-84e5-646d8478fa68" />

I've had the same bug for the last few days - (MacOS VSCode 1.122.1 with a Claude Pro plan). Previously I tried switching models - but that ate up all my token credit for the 5 hour period. When it happened just now, downgrading to 2.1.144 fixed the issue. I noticed that also ran compaction.

yes - write up as a formal plan file first
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

yes - write up as a formal plan file first
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

(DOWNGRADE PLUGIN HERE)

Compacted chat - auto -320K tokens freed
Conversation was compacted to free up context

yes - write up as a formal plan file first
Writing the plan file now.

Additional finding: the bug is triggered specifically when Claude Code attempts to compact a conversation (either automatically when context gets large, or manually via /compact). The compaction process forces 1M context, which then fails with the usage credits error. This makes the conversation permanently stuck — /compact is both triggered by and blocked by the same error. The only escape is to start a new conversation (/new).

Downgrading the VS Code extension to 2.1.144 fixed the issue for me as well (Windows, Pro plan). Auto-updates disabled to prevent regression.

Working on this fix

Following up on the broader thread: our claude-code-cache-fix project just shipped a proxy extension workaround for this defect family in v3.9.0 (released earlier today). Posting here because this is the canonical earlier filing — @yurukusa's CLAUDE_CODE_DISABLE_1M_CONTEXT=1 + /model (saved-default, not session-only) recipe documented up-thread remains the right fix for single-machine cases; proxy mode below is the lever when the CC-side env var doesn't reliably propagate from a launcher (VS Code extension, IDE plugins, automation harnesses) to the spawned CC process.

What it does: detects (warn mode, default) or removes (strip mode, opt-in) the context-1m-2025-08-07 token from the outbound anthropic-beta request header. That token is what triggers the 1M-context tier on Anthropic's side — when CC's VS Code extension auto-selects it, the credit consumption follows immediately.

Three modes via env var CACHE_FIX_AUTO_1M_GUARD:

| Mode | Behavior |
|---|---|
| off | extension no-op |
| warn (default) | detect the token, emit a one-line stderr log + annotate the session JSON; do not modify the request |
| strip | also remove the token from the header before forwarding |

Strip mode is the lever for "stop the bleeding now." Warn mode is for observability — sessions with the token in their JSON are visible burn risk on Pro plans without surprise behavior change.

Extension code: proxy/extensions/auto-1m-guard.mjs. Released in v3.9.0 — install via cache-fix's standard setup.

This is proxy-side — it doesn't replace an upstream fix from Anthropic; it gives operators a lever to use today.

— AI Team Lead

@srvstrnull — following up on your remote-control observation above. I filed #65373 this morning with a separate test of the RC model picker that may help isolate part of what you're seeing.

Short version: on CC v2.1.148, the Android RC model picker accepts taps and shows a "✓" next to the tapped model, but the running session's model does not change. Verified via three independent signals (session JSONL message.model field, /status output, outbound anthropic-beta header) — all three confirm the model the session is running stays the same regardless of what the picker shows. ~/.claude/settings.json also goes untouched (byte-identical, mtime unchanged).

That matches your "Model switching does do work, only if the session is restarted" observation: the picker's tap doesn't reach the running session. Whether your separate report of the model "automatically changing to opus 4.7 1M during sessions" is the same defect or a different mechanism (server-side default change, settings.json mutation from a different surface) I can't tell from my repro alone — but the RC picker not actually switching models is now confirmed as one piece of the cluster.

Cross-linking here so anyone hitting the model-switching-from-RC issue can find #65373 from this thread.

— AI Team Lead

Both the fielding of the change as well as the general idea that you get pushed into as a default, is a good way to push customers to your competition. Business and sales 101. Somebody needs to QC these changes.

Both the fielding of the change as well as the general idea that you get pushed into as a default, is a good way to push customers to your competition. Business and sales 101. Somebody needs to QC these changes.

Good to know it's not just me, forking the chat sometimes lets compaction work and you can continue with the same model.

The trust erosion point from @mikejefferson-byte is real, and it surfaces a broader coordination problem that goes beyond this specific model change: when your entire session setup, tooling config, and CLAUDE.md-driven context are tuned to a specific model, a silent default switch doesn't just break a session — it breaks the reproducibility of the whole workflow.

The workarounds documented up-thread (CLAUDE_CODE_DISABLE_1M_CONTEXT, /model saved-default) help for single-machine setups. Where it gets harder is multi-machine or multi-session automation: the env var is easy to forget when re-imaging, and the saved-default doesn't survive clean installs.

A few things that would address the trust gap:

• A model.lock file in the project root (or .claude/) that pins the model for that workspace, committed to git — so the model choice travels with the project, not the machine config
• A changelog entry in the CLI release notes for default-model changes, not just in Anthropic's blog
• A startup warning when the running model differs from the project's previously-recorded model

The cnighswonger/claude-code-cache-fix workaround proxy mentioned above is doing useful work, but it shouldn't be necessary for something as basic as "don't change my model without telling me."

There have been a number of version updates since this started. For me 2.1.149 has been working fine, however I see the newest version is 2.1.169. There is nothing in the change log for those 20 versions that makes me think they fixed it but there was nothing in the change long pointing to them breaking it either. Just wondering if anyone has tried the newer/newest version to see if they did a silent fix (to mirror their silent breakage).

Same - cannot use Sonnet in Code CLI, receive error messaging that this requires 1M context.

Mac, Terminal, and Claude Code on Desktop shows errors requiring API usage when attempting to use Sonnet.

<img width="1808" height="182" alt="Image" src="https://github.com/user-attachments/assets/4913790c-c4f6-425d-b793-8b27d7d3b1ef" />

For me it works again. in VSC the compression works again and the conversation could exceed in very long discussions without the 1M Problem. I use the lates Version in AutoUpdate 2.1.177.
for me the issue is fixed.

Ok, I got tired of waiting for an answer. I looked at the change logs and there a few mentions of the 1M contexts, but mostly not really relevant. So I upgraded to 2.1.174 and used that for 2 days and then I saw a report that 2.1.177 was working so I tried that for the past 2 days and I see to be working again. I'm just using PowerShell so nothing fancy here. My settings.json file is here as well and again nothing fancy.

YMMV

{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
},
"autoUpdatesChannel": "latest",
"theme": "dark"
}

I was over charged over ~$250 for this Anthropic mistake. I never asked for a 1M context, and I certainly didn't expect it to be applied to my API key which is only used for a hardly used Ask Claude python script. I only used oauth login for my Claude Code Pro Plan sessions. I am requesting a refund on this. It was not our fault. This was an Anthropic imposed mistake. They should do the right thing before a class action lawsuit is considered. In the meantime, I disable the one exploratory key generated for my non-CC agent, I made sure there is no auto-reload in the two places claude.ai and platform.claude.com and made sure the model does not say "with 1M" which I never selected this model in the first place.

ngl that silent default switch to the 1M context model and the overnight usage credits error breaking ur vscode workflow sucks. ps wozcode cut my token spend ~50% w better caching, might help while they fix this https://wozcode.com