sonnet[1m] and fable[1m] model aliases do not apply 1M context window (only opus[1m] works)

Status Open

Reported on v2.1.201

Maintainer reply None cached

Activity 4 comments · opened Jul 5, 2026

Description

The [1m] model alias suffix (documented at https://code.claude.com/docs/en/model-config) works correctly for Opus, but does not apply the 1M context window for Sonnet or Fable, even though both models support 1M context at the API level (per https://platform.claude.com/docs/en/about-claude/models/overview).

Steps to reproduce

Run /model opus[1m]

Confirmation: "Set model to Opus 4.8 (1M context)" ✅ label present
Status line reports total context window as 1.0M ✅

Run /model sonnet[1m]

Confirmation: "Set model to Sonnet 5" ❌ no "(1M context)" label
Status line reports total context window as 200.0k ❌

Run /model fable[1m]

Same result as Sonnet: confirmation drops the "(1M context)" label, status line stays at 200.0k

Expected behavior

sonnet[1m] and fable[1m] should apply a 1,000,000 token context window and report it in the /model confirmation and in the context_window.total_tokens field passed to the status line, consistent with opus[1m].

Actual behavior

Only opus[1m] actually engages the 1M context window. sonnet[1m] and fable[1m] silently fall back to the standard 200k window with no error or warning.

Environment

Claude Code version: 2.1.201 (confirmed up to date via claude update)
OS: macOS 26.5.1 (BuildVersion 25F80)
Plan: Enterprise / Claude for Work
~/.claude/settings.json has "model": "sonnet[1m]" explicitly pinned — same result as using /model sonnet[1m] interactively
No ANTHROPIC_MODEL / CLAUDE_CODE_MODEL env vars set that could override the alias

Additional notes

This does not appear to be a plan/entitlement gate — the platform docs state 1M context is generally available (GA, no surcharge) and enterprise plans have no separate toggle to enable it.
Possibly related to prior reports of the Sonnet 1M status-bar/context mismatch, e.g. #61734 and #26428, though those predate the current Sonnet 5 / Fable 5 models and were closed as not planned — this report is specifically about the [1m] alias not taking effect (not just a status-bar display issue) for non-Opus models on the current CLI version.

View original on GitHub ↗

4 Comments

k2-60 · 1 month ago

Working for me in settings.json is
claude-fable-5[1m]
claude-opus-4-8[1M]

eggrollofchaos · 1 month ago

Data point that may help narrow this down: same symptom here (sonnet[1m] not applying 1M) on Claude Code 2.1.201.

Root cause looks tied to running behind a proxy on ANTHROPIC_BASE_URL — in my case, the Headroom proxy this environment routes through.

Docs actually promise this should work. Two passages, same page:

Model aliases table (#model-aliases):

sonnet[1m] — Uses Sonnet with a 1 million token context window for long sessions. No effect when sonnet already resolves to Sonnet 5 with its native 1M window; behind an LLM gateway, selects the 1M window for Sonnet 5

Sonnet 5 context window section (#sonnet-5-context-window):

Two configurations budget the window at 200K instead and auto-compact at that boundary: LLM gateway: when ANTHROPIC_BASE_URL points at a gateway, Claude Code can't verify 1M support. To use the full window, select Sonnet 5 (1M context) in the model picker, which maps to sonnet[1m].

So per docs, selecting sonnet[1m] directly should get the 1M window even behind a gateway. In practice, behind Headroom, it didn't — matches OP exactly (confirmation drops the "(1M context)" label, /context stays 200k).

Separately: /model sonnet[1m] was flatly rejected ("not available for your account") until I first selected opus[1m] once and restarted — after that, sonnet[1m] became selectable. Hunch, not a confirmed mechanism (some client-side eligibility state flips).

The fix that reliably worked: unset ANTHROPIC_BASE_URL for the session (bypass the proxy entirely). Then sonnet[1m] applies correctly and persists.

Related: #60913 — same class of bug (a Headroom-style proxy breaking [1m] handling); opus[1m] there reverts to 200k silently on session resume.

devisioncx · 1 month ago

Another data point ruling out the proxy theory: same symptom on 2.1.201 with no ANTHROPIC_BASE_URL and no CLAUDE_CODE_DISABLE_1M_CONTEXT. Claude Enterprise plan.

sonnet[1m], claude-sonnet-5[1m] and claude-fable-5[1m] are all accepted by /model (Fable shows "Draws from usage credits"), but the context window stays at 200k. Only opus[1m] (Opus 4.8, the subscription-included auto-upgrade path) actually gets the 1M window.

We checked the org side thoroughly: /status shows Setting sources: User settings, Enterprise managed settings (remote), but the remote managed settings content is literally just {"channelsEnabled": true} — no model restrictions, no context policy. Admin console shows no model limitations either.

So for Enterprise accounts this looks like a server-side entitlement issue: per the docs, Sonnet 5 "always runs with the 1M context window — there is no 200K variant", yet it's budgeted at 200K here with a completely clean config. The Opus 1M entitlement path works; the Sonnet 5 / Fable 5 path doesn't.

superuser7777 · 1 month ago

I am the same. Reproduce the situation.
1M enable/disable selection is random.

Three types of 1M are mixed.
If you select/determine sonnet[1M], sonnet will be fixed to 200k for that Session.
Strangely enough, 1M selection is restored even in sesshons that were fixed when other sesshons happened to be able to select 1Msonnet.

"env": { "CLAUDE_CODE_DISABLE_1M_CONTEXT": "0", },

--
By the way, I would like Anthropic to stop dynamically lowering effort (I can only think) in response to the server being unavailable. I hope that at least MAX20 users will respond honestly.