[Bug] 1M context window not auto-applied on Max plan in Claude Code CLI v2.1.114 (plus: `--model` flag silently drops `[1m]` suffix)

Summary

Two related issues in Claude Code CLI v2.1.114 that combine to silently deny Max-plan subscribers the 1M context window they're entitled to per the documentation:

1. Primary bug: Per the official model-config documentation, Max/Team/Enterprise plans are supposed to receive the 1M context window for Opus automatically with no configuration. On v2.1.114 this auto-upgrade does not fire. A fresh Max-plan session with plain claude-opus-4-7 reports /200k in /context.
2. Related trap: Even when a user manually opts into the 1M variant via /model claude-opus-4-7[1m] (which persists to ~/.claude/settings.json and works correctly on plain claude invocations), any launcher that passes --model claude-opus-4-7 via CLI flag overrides settings.json and silently strips the [1m] suffix. Same happens with model-naming env vars like ANTHROPIC_MODEL and CLAUDE_CODE_SUBAGENT_MODEL.

Combined effect: users who followed every documented path (Max subscription, used /model workaround, set up proper launcher scripts) still end up on /200k without knowing it. Our team ran at least three days on /200k because of this before diagnosing it — sessions compacting every 10-15 minutes instead of every few hours.

Documentation reference

From <https://code.claude.com/docs/en/model-config> (section: Extended context):

"On Max, Team, and Enterprise plans, Opus is automatically upgraded to 1M context with no additional configuration."

Pricing note from same doc page:

"The 1M context window uses standard model pricing with no premium for tokens beyond 200K."

So this is not a billing-tier mismatch. The feature is documented as automatic on qualifying plans with no cost delta.

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Code CLI: v2.1.114 (same behavior observed on v2.1.112)
• Plan: Max (banner confirms: Claude Max)
• Shell tested: both cmd.exe and PowerShell 7 — same outcome on each

Relevant env-var state for the primary-bug reproduction (no overrides that should suppress auto-upgrade):

CLAUDE_CODE_DISABLE_1M_CONTEXT=          <-- NOT SET
ANTHROPIC_MODEL=                         <-- NOT SET
ANTHROPIC_DEFAULT_OPUS_MODEL=            <-- NOT SET
CLAUDE_CODE_SUBAGENT_MODEL=              <-- NOT SET (for this test)

---

Bug #1: Max-plan auto-upgrade does not fire

Reproduction

1. On a Max-plan account, ensure ~/.claude/settings.json contains plain "model": "claude-opus-4-7" (no [1m] suffix).
2. Verify no env-var override: echo $CLAUDE_CODE_DISABLE_1M_CONTEXT returns empty; echo $ANTHROPIC_MODEL returns empty.
3. Launch claude directly from cmd.exe (no wrapper bat, no env-var overrides on the command line).
4. Run /context.

Observed

 ▐▛███▜▌   Claude Code v2.1.114
▝▜█████▛▘  Opus 4.7 with high effort · Claude Max       <-- banner identifies account as Claude Max
  ▘▘ ▝▝    C:\Users\TJ

❯ /context
Context Usage
Opus 4.7
claude-opus-4-7                                          <-- no [1m] suffix
22.4k/200k tokens (11%)                                  <-- /200k, not /1m

System prompt:    8.3k tokens (4.1%)
System tools:    13.1k tokens (6.6%)
Memory files:     298 tokens (0.1%)
Skills:           689 tokens (0.3%)
Messages:          13 tokens (0.0%)
Free space:     144.6k (72.3%)
Autocompact buffer: 33k tokens (16.5%)

Autocompact fires at approximately 200k - 33k = 167k. Baseline load (system prompt + tools + memory + skills) consumes ~44k before any user message, leaving ~123k of true working room. On a busy research session this triggers compaction every 10-15 minutes.

Expected

Per the docs, on a Max-plan account with no CLAUDE_CODE_DISABLE_1M_CONTEXT override, /context should show a /1m denominator and autocompact should fire much later in the session. It does not.

Workaround (verified)

Running /model claude-opus-4-7[1m] in the session immediately flips the denominator and persists the choice to ~/.claude/settings.json. After running it and restarting:

 ▐▛███▜▌   Claude Code v2.1.114
▝▜█████▛▘  Opus 4.7 (1M context) with high effort · Claude Max
  ▘▘ ▝▝    D:\users\tj\projects

❯ /context
Opus 4.7 (1M context)
claude-opus-4-7[1m]
41.2k/1m tokens (4%)                                     <-- /1m as expected
Free space: 925.8k (92.6%)
Autocompact buffer: 33k tokens (3.3%)

This proves the 1M variant is fully wired and functional in v2.1.114. The bug is specifically that the auto-upgrade for Max plans is not happening despite the docs stating it should be automatic. Max-plan users who don't know about the [1m] model-suffix syntax never get the feature they're paying for.

---

Bug #2: --model CLI flag silently strips [1m] suffix (launcher trap)

Why this matters

Users who discover the [1m] workaround often persist it via /model claude-opus-4-7[1m] so ~/.claude/settings.json contains "model": "claude-opus-4-7[1m]". They reasonably expect all subsequent sessions to inherit 1M context. They don't, if they launch via a script that passes --model.

This is how we burned at least three days on /200k after having done the manual workaround weeks earlier. Our launcher bat files passed --model claude-opus-4-7 (no [1m]), and the CLI flag silently overrode the correctly-configured settings.json.

Reproduction

1. On a Max-plan account, set ~/.claude/settings.json to "model": "claude-opus-4-7[1m]" — via /model claude-opus-4-7[1m] in any session, or by hand-editing.
2. Confirm the settings.json change persisted (file contains "model": "claude-opus-4-7[1m]").
3. Launch claude directly from any terminal — verify /context shows /1m and claude-opus-4-7[1m] (the primary workaround working correctly).
4. Now launch claude --model claude-opus-4-7 (note: plain model-id, no [1m]).
5. Run /context.

Observed

❯ /context
Context Usage
Opus 4.7
claude-opus-4-7                                          <-- [1m] stripped
101.6k/200k tokens (51%)                                 <-- /200k, despite settings.json having [1m]

The CLI --model flag with a plain model-ID overrides settings.json and silently strips the [1m] suffix. No warning is emitted. The user has no feedback that their manual opt-in has been silently undone.

Same behavior for env vars

The precedence chain appears to be: CLI flag > env var > settings.json. Any layer that names a plain model-ID without [1m] silently strips the suffix from the layers below. We observed the same silent strip with:

• --model claude-opus-4-7 CLI flag
• ANTHROPIC_MODEL=claude-opus-4-7 env var (documented in research/environment-variables.md)
• CLAUDE_CODE_SUBAGENT_MODEL=claude-opus-4-7 env var (affects subagents spawned via the Agent tool — they end up on /200k even when the main session is on /1m)

Fix on user side

Every launcher script and env var that names a model explicitly must include the [1m] suffix:

REM Wrong — silently strips [1m] on Max plans
set CLAUDE_CODE_SUBAGENT_MODEL=claude-opus-4-7
claude --model claude-opus-4-7 --effort max %*

REM Correct
set CLAUDE_CODE_SUBAGENT_MODEL=claude-opus-4-7[1m]
claude --model claude-opus-4-7[1m] --effort max %*

But this is load-bearing knowledge that isn't documented in claude --help or the --model flag description.

---

Documentation gap

claude --help describes the --model flag as:

--model <model>   Model for the current session. Provide an alias for the latest model
                  (e.g. 'sonnet' or 'opus') or a model's full name (e.g. 'claude-sonnet-4-6').

There is no mention of the [1m] model-suffix syntax, no mention that it's required on qualifying plans for 1M context, and no mention that passing a plain model-ID silently drops [1m] if it was set in settings.json. The syntax is only documented at <https://code.claude.com/docs/en/model-config> under "Extended context" — and even there it's described as automatic, not opt-in.

Related real issues

• #50688 — statusline context % stale after /compact until next assistant turn (suggests known display-refresh issues, but does not explain why /200k is the limit not just the display)
• #50732 — context % accounting bug (WSL)

Neither covers "1M auto-upgrade not applied on Max plan" or the launcher-trap finding.

Asks

1. Fix the Max-plan auto-upgrade path so plain claude-opus-4-7 routes to the 1M variant automatically as documented. The feature works (the [1m] variant is fully wired); the auto-upgrade just doesn't fire.
2. Document the [1m] model-suffix syntax in claude --help under --model, and mention it in the documentation for every model-naming env var (ANTHROPIC_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL, CLAUDE_CODE_SUBAGENT_MODEL).
3. Consider emitting a warning when a --model CLI flag or model-naming env var strips [1m] from a settings.json model that had it. Silent layer-override is the worst-case UX here because users think they've opted in and have no feedback that they haven't.
4. Include the [1m] variant in the /model picker's default listing on qualifying plans so users discover it without having to type a suffix they didn't know existed.
5. Clarify the precedence chain in the model-config docs (CLI flag > env var > settings.json) so users debugging "why is this session /200k?" have a documented diagnosis order.

Why this matters

Frequent compaction in long research or refactor sessions causes:

1. Context loss — compacted summaries are lossy. Re-establishing context after compaction wastes user time and can lose critical detail the model would otherwise use directly.
2. Latency — compaction itself takes seconds and disrupts flow.
3. Cost — every compaction is an additional model round-trip.
4. Plan value erosion — the 1M context window is a key documented Max-plan benefit. When users "do everything right" (subscribe to Max, run /model [1m], set up launcher scripts) and still end up on /200k without knowing, the feature they're paying for is silently denied.

Our measured window for this: at least three days (confirmed 2026-04-16 → 04-19; likely longer, since the launcher pattern that triggered the trap predates the Opus 4.7 rollout). Every compaction in that window was preventable.

---

Public writeup of the investigation, including reproduction tooling and a diagnosis checklist: <https://github.com/LostBeard/claude-crew/blob/main/research/1m-context-investigation.md>.

Collaboration note: This report was drafted collaboratively with Claude Code (Opus 4.7) acting as accessibility aid (social-anxiety filter on technical correspondence) and peer reviewer. All /context outputs, claude --help quotes, and reproduction steps were verified against live v2.1.114 output in my terminal before filing.