[Bug]: Claude Code model picker is stale and connection test hides the resolved model

[MumuTW]

What happened?

The Claude Code model picker uses a hard-coded fallback catalog that still recommends:

• claude-opus-4-5
• claude-sonnet-4-5
• claude-haiku-4-5

This catalog is stale. Anthropic's current primary model lineup includes:

• claude-fable-5
• claude-opus-5
• claude-sonnet-5
• claude-haiku-4-5

The same stale list is present on the current main branch as of 2026-07-28:
https://github.com/nexu-io/open-design/blob/main/apps/daemon/src/runtimes/defs/claude.ts#L6-L14

Because Claude Code does not expose a machine-readable list-models subcommand, this fallback list becomes the primary set of explicit suggestions shown to users. Rolling aliases partially mitigate the problem, but the UI still prominently recommends obsolete pinned model IDs.

Open Design Cloud already recognizes claude-fable-5, making the two model catalogs inconsistent. Fable 5 should be an explicit first-class choice in the Claude Code picker, not only something advanced users can discover and type into the Custom field. It is a particularly important option for frontend/UI work and is likely to be a common user selection.

There is also a related transparency problem in the connection test. If a user selects opus (alias) and clicks Test, the success message only says that Claude Code replied in N milliseconds. It does not reveal which concrete model the alias resolved to, so the test cannot actually confirm the model selection.

This is not an upstream limitation: Open Design already parses the concrete model from Claude's system/init stream event in apps/daemon/src/runtimes/claude-stream.ts (obj.model). However, the connection-test sink ignores that status event, ConnectionTestResponse.model continues to contain the requested slot (opus), and the frontend success copy does not display any model.

Steps to reproduce

1. Install and open Open Design 0.16.1 on macOS.
2. Open Settings.
3. Find the Claude Code agent card.
4. Open the model picker.
5. Observe that the explicit model list only contains Claude 4.5 models.
6. Observe that Claude Fable 5, Opus 5, and Sonnet 5 are absent.
7. Select Opus (alias) and click Test.
8. Observe that the success result reports only the agent name, latency, and sample (OK), without the concrete model that answered.

Expected behavior

The built-in fallback list should reflect Anthropic's current model lineup, for example:

• Best available (alias)
• Sonnet (alias)
• Opus (alias)
• Haiku (alias)
• claude-fable-5
• claude-opus-5
• claude-sonnet-5
• claude-haiku-4-5

Fable 5 should be present as an explicit option because it is a major current model and a common choice for frontend/UI work.

When testing an alias or the CLI default, the result should display the concrete model reported by Claude Code, for example:

Claude Code replied in 812 ms — Model: claude-opus-5 — OK

The response contract should preserve both values rather than overloading one field:

• model: requested selection, such as opus or default
• resolvedModel (or reportedModel): concrete model reported by the CLI, such as claude-opus-5

Relevant Anthropic documentation:
https://platform.claude.com/docs/en/about-claude/models/choosing-a-model

Open Design version

0.16.1

Platform

macOS (Apple Silicon)

Additional context

Anthropic provides an authenticated Models API at GET /v1/models, even though Claude Code itself does not expose a machine-readable list-models subcommand:

https://platform.claude.com/docs/en/api/models/list

A more robust discovery and fallback strategy would be:

1. Query /v1/models when an Anthropic API key is available.
2. Prefer rolling Claude Code aliases (best, sonnet, opus, haiku) for subscription and CLI-only users.
3. Maintain a small, current fallback catalog for explicit model IDs, including Fable 5.
4. Keep Custom model ID support for gateways and third-party providers.
5. Add a test or release checklist that prevents retired model generations from remaining the primary built-in suggestions.

Claude Code supports --model <alias|name>, and rolling aliases are safer fallback choices because they can resolve to provider-appropriate recommended versions:

https://code.claude.com/docs/en/model-config

A minimal implementation for resolved-model reporting appears to be:

1. Capture model from the existing Claude status/initializing event in createAgentSink() instead of discarding it.
2. Add an optional resolvedModel/reportedModel field to ConnectionTestResponse.
3. Return it from successful local-agent tests.
4. Append it to the existing localized success message, avoiding duplicate display when it equals the requested exact ID.
5. Add a regression test covering opus as the requested alias and claude-opus-5 as the reported concrete model.

Major Claude model releases are infrequent enough that retaining outdated Claude 4.5 entries across multiple generations appears to be a fallback-catalog maintenance failure rather than an unavoidable technical limitation.

Preflight

• I searched existing open issues and confirmed this is not a duplicate.
• This report includes the real behavior, reproduction steps, expected result, app version, and platform.

[open-design-bot]

🎉 ✨ Welcome to Open Design, @MumuTW!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @MumuTW — thanks for the careful write-up. The reproduction, code link, and model-doc references made this one easy to verify.

Confirmed from our side: main still hardcodes the Claude Code fallback list in apps/daemon/src/runtimes/defs/claude.ts, and that built-in picker list is still centered on the 4.5-era pinned IDs. I also checked Anthropic's current docs today (July 28, 2026): the Claude platform docs now point users toward Fable 5 / Opus 5 / Sonnet 5 / Haiku 4.5, and the Claude Code model-config docs describe rolling aliases like best, fable, sonnet, opus, and haiku, so the current Open Design suggestions are behind the current upstream guidance.

There is already related work in flight on this exact area:

• fix(daemon): refresh Claude Code fallback model list to the current generation #6095 refreshes the Claude fallback catalog and adds regression coverage around the stale-list problem.
• fix(daemon): add current-generation Claude models to the picker #6051 also updates the picker toward the current generation.
• Support refreshing Local CLI model lists instead of relying on hardcoded built-ins #5729 tracks the broader follow-up of refreshing Local CLI model lists instead of relying on static built-ins.

So this issue is a real bug report, not just a docs mismatch. We'll keep it linked to the work above until one of the fixes lands. If you notice a gap in either PR — especially around alias-first behavior vs pinned IDs — feel free to call it out here.

[lefarcen]

Heads-up: PR #6183 is open for the resolved-model transparency slice from this issue. It keeps the requested alias/default slot in the connection-test response, adds an optional resolvedModel field for the concrete CLI-reported model, and updates Settings to show that resolved model after a successful Local CLI test. Keeping this issue open until that lands — the broader fallback-model catalog side is still tracked separately.

[lefarcen]

PR #6386 is the resubmitted fix for the resolved-model transparency part of this issue. It keeps the requested alias/default slot in model, adds an optional resolvedModel field from the Local CLI test path, and updates the Settings success message to show the concrete model when it differs from the selected alias. Keeping this issue open until that PR lands.