[BUG] Claude Code *Desktop* app lost the ability to select 1M Context variants of models for 3p inference

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/69109
2. https://github.com/anthropics/claude-code/issues/68287
3. https://github.com/anthropics/claude-code/issues/36351

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

如何解决这个问题

如何解决这个问题

/model claude-opus-4-8[1m]

手动输命令可以强制选1M

> 如何解决这个问题 /model claude-opus-4-8[1m] 手动输出命令可以强制选1M

这个我知道 但是每次开新窗口或者重新打开软件就还要输入 有点麻烦

> > 如何解决这个问题 > > > /model claude-opus-4-8[1m] > 手动输出命令可以强制选1M 这个我知道 但是每次开新窗口或者重新打开软件就还要输入 有点麻烦

那目前应该没办法了，只能等官方修；或者试试改配置，里边手动加个1M的配置试试

same here:

<img width="1525" height="721" alt="Image" src="https://github.com/user-attachments/assets/b944d19c-f774-4018-bafb-169ccecfd64a" />

Root cause + suggested fix (from the shipped app code)

Adding root-cause detail on top of the symptom already documented here. This isn't only the picker hiding the 1M variants — the 3p desktop actively strips the [1m] signal before it reaches the child, so even a running session is capped at 200K. Two code paths combine:

1. The config transform stores the base name and drops [1m]. The transform that normalizes inferenceModels captures supports1m but keeps only the base name (in effect):

const m = t.name.match(/^(.+?)\[1m\]$/i);
// stores m[1] (base, WITHOUT [1m]) instead of m[0] (full "name[1m]")
return m ? { ...t, name: m[1].trim(), supports1m: !0 } : t;

supports1m is used for the picker badge but never re-consulted when building the child's --model, so the child is spawned with e.g. claude-opus-4-6 (no suffix).

2. [1m] is the child's main 1M trigger — which is exactly why @GentlemanHu's /model claude-opus-4-8[1m] workaround works: it re-supplies the suffix the app dropped:

function is1m(model){ if (killSwitch()) return false; return /\[1m\]/i.test(model); }
// is1m(model) === true  → 1_000_000 window AND attaches the context-1m-2025-08-07 beta
// otherwise             → 200_000

3. The beta fallback is also closed, because the 3p desktop spawns the child with CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS="1", which removes context-1m-2025-08-07 from the beta set. So both routes to 1M are shut at once, silently — no error, picker still shows the model as 1M-capable.

Reproduces beyond Bedrock: same behavior on a LiteLLM-style OpenAI-compatible gateway (Windows desktop) for Opus 4.5/4.6 and Sonnet 4.5/4.6; Haiku correctly stays 200K. Verified locally that letting the [1m] survive to the child restores a 1,000,000-token window for all of them, and reverting returns them to 200K — so the defect is isolated to the desktop's name transform + forced-betas-off, not the models, the gateway, or the child's window logic.

Suggested fix (you already record everything needed): honor supports1m when constructing the child model argument — simplest is to keep the full match (m[0]) in the transform so [1m] survives, or re-append it at spawn when supports1m === true. Additionally, avoid force-setting CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 for 3p (or make it configurable) so the context-1m-2025-08-07 path stays available. Either one restores 1M for 3p/enterprise without users having to retype /model ...[1m] every session.

Still reproduces on Desktop 1.17377.1 (3p / gateway inference).

Confirming the regression is still present in the current build. The [1m]-stripping transform described above is unchanged in 1.17377.1's app.asar — the only difference from earlier builds is that the minified variable in the transform was renamed (earlier i/n → now r), i.e. that code was re-touched but the strip itself was not fixed. The child claude-code process is still spawned with the base name (no [1m]), and CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS is still forced to "1", so both routes to 1M stay closed.

This build also added supports1m help text in the picker UI, yet the value still isn't honored when building the child --model — so the picker advertises 1M while sessions silently cap at 200K.

Repro unchanged: 3p LiteLLM-style OpenAI-compatible gateway, Opus 4.5/4.6 and Sonnet 4.5/4.6 (Haiku correctly stays 200K). Letting the full name[1m] survive to the child restores a 1,000,000-token window for all of them; reverting returns them to 200K.

Update: still reproduces on Desktop 1.19367.0.

Updated to the latest build today (from 1.17377.1) — no change to the defect. The [1m]-stripping transform is still present in app.asar (2 occurrences), and CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS is still force-set to "1". The only churn is cosmetic: the minified variable in the transform changed again — this build actually uses two different vars across the two copies (n and Q), where the previous build had r in both. supports1m is still referenced in the picker UI (~14×) but still isn't honored when building the child --model.

So the 3p Opus/Sonnet 1M variants continue to silently cap at 200K (Haiku correctly stays 200K). Same one-line fix still restores 1M: keep the full name[1m] (the transform's full match) instead of the base group, or re-append [1m] at spawn when supports1m === true.

Timeline with no fix: 1.14271.0 (first broken) → 1.15962.x → 1.17377.1 → 1.19367.0.