Desktop app: expose Opus 4.6 [1m] with extended thinking, or honor settings.json `model` override

Summary

The Claude Code desktop app's model picker (⇧⌘I) is restricted to a curated list: Opus 4.7, Opus 4.7 [1m], Sonnet 4.6, Haiku 4.5. Opus 4.6 is not selectable. The model field in ~/.claude/settings.json is honored by the terminal CLI but ignored by the desktop app, leaving no GUI path to Opus 4.6 with extended thinking. The only in-app workaround is /fast, which is a speed-optimized mode and does not preserve extended-thinking depth.

Request

Either (preferred) add Opus 4.6 and Opus 4.6 [1m] to the desktop model picker, or have the desktop app honor the model field in settings.json as an override. The latter is probably the lower-lift fix and gives power users a general escape hatch without expanding the curated UI.

Rationale

I do sustained, multi-session work that depends on long-context retrieval and careful problem framing — experimental analysis, cross-referencing prior runs against a large memory corpus, tracing gradient paths through architecture decisions. In this workload I've observed Opus 4.7 exhibiting patterns that Opus 4.6 [1m] with extended thinking did not:

• Long-context retrieval weakness. The Opus 4.7 System Card (§8.7.2, OpenAI MRCR v2, 8-needle) documents a sharp regression vs Opus 4.6. The 4.6 configuration tested is specifically "64k ext thinking" — exactly the configuration being removed from the desktop app:

| | Opus 4.6 (64k ext thinking) | Opus 4.7 (max) |
|---|---|---|
| MRCR v2 @ 256k (8-needle) | 91.9% | 59.2% |
| MRCR v2 @ 1M (8-needle) | 78.3% | 32.2% |

A 46-point collapse at 1M. For reference, Opus 4.6 with extended thinking also outperforms GPT-5.4 (xhigh) and Gemini 3.1 Pro (thinking:high) at both context lengths on this benchmark.

• Test-time compute scaling on agentic search. §8.8.2 (BrowseComp, 10M token limit): Opus 4.6 = 83.7% vs Opus 4.7 = 79.3%. The card itself states: "Opus 4.6 has a better test-time compute scaling curve than Opus 4.7 and was able to achieve a better score on BrowseComp… we recommend users to experiment with both models on their specific use case." The desktop UI removing Opus 4.6 directly contradicts this guidance — users can't experiment with both if only one is selectable.

• Gaps in sustained reasoning. Chains of inference break or revert to surface-level pattern matching on long tasks that 4.6 [1m] held together.

• Premature closure. Rush to land on an answer before the problem is adequately scoped — symptoms get treated as root cause.

• Skipped problem framing. Action taken before the problem statement is pinned down; the model solves the wrong thing accurately rather than the right thing approximately.

The MRCR and BrowseComp regressions are the quantified spine under the qualitative bullets. For workflows where multi-needle retrieval across accumulated session/memory context is load-bearing, /fast is not a substitute — it runs 4.6 but trades away the extended-thinking depth that produces the 91.9%/78.3%/83.7% numbers above.

Environment

• Claude Code desktop app (Mac)
• ~/.claude/settings.json contains "model": "claude-opus-4-6[1m]" — ignored by desktop, honored by CLI
• /model <id> in the desktop input returns: "/model isn't a recognized command here. Some commands only work in the Claude Code terminal."
• Current workaround: launch claude in a terminal, which works but loses parity with GUI features (worktree UI, routines, session sidebar, activity dashboard)

Suggested fixes (in order of user-power preference)

1. Expose Opus 4.6 and Opus 4.6 [1m] in the desktop picker alongside 4.7 variants
2. Have the desktop app honor settings.json model — consistent with CLI, preserves curated default UI
3. Accept /model <id> in the desktop input as it does in the CLI