claude-code - 💡(How to fix) Fix [Bug] 1M context window not auto-applied on Max plan in Claude Code CLI v2.1.114 (plus: `--model` flag silently drops `[1m]` suffix) [3 comments, 3 participants]

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.