[Feature] Provider-first two-step model picker in the composer (plus a direct reasoning-effort slider)

[codeOct]

[Feature] Provider-first two-step model picker in the composer, plus a direct reasoning-effort slider

Motivation

With more than one configured route, the composer model seat is hard to use. ModelSelect opens one continuous scroll: every provider group heading and every model under it is in the single pane === 'model' list. Providers are already grouped, but a group heading is a label, not a level you can enter — so the only way to reach a model is to scroll past every provider above it.

That cost scales with the product of providers and models, which is exactly the shape a multi-route setup has:

• A single ordinary session with the built-in OpenRouter route returns 276 models (confirmed on Windows 11 in #2352).
• A local profile here (dsh 0.1.7-rc.2, Windows 11) holds four-plus provider groups in that one pane: a subscription route with 18 known models, an OpenAI-compatible route with 7 models, the two built-in DeepSeek groups, and the routes third-party login plugins register. Selecting a model means scrolling through all of them.
• Reasoning effort is a second nested trip: open the menu, drill into Effort, pick a level, and the menu closes.

Two changes make this scale. They are independent, so they can land separately.

1. Provider first, then model

The model pane becomes two levels: a provider level that lists each provider group (name, model count, current marker), and the existing model level narrowed to the chosen provider with a Back row. This is the drill-down the menu already uses for its own Model/Effort rows, applied one level deeper — no new interaction pattern is introduced.

The reason this is worth doing in addition to the search field proposed in #2352, #4211, #4842 and #5122 is that the two solve different problems. Search assumes you already know the model's name; with 276 rows you often know the route you want ("the OpenRouter one") and not which of its ids is current. Provider-first also turns an O(providers × models) scan into O(providers) + O(models of one provider), and it makes the trigger's meaning explicit: the selection is a provider plus a model, and the picker currently never lets you act on the provider half of that pair.

Suggested behavior:

• Root pane keeps its Model / Effort cell pair. The Model cell now drills into the provider list; its current value still shows the model name.
• Provider rows show the provider name, its model count, and the current-provider marker; the row of the provider in use carries the checked state.
• Entering a provider shows only that provider's models, and lands focus on the model in use (or the first row).
• Back returns to the provider list and hands focus back to the cell that opened the pane, matching the existing back() contract.
• Collapse the provider level when only one provider is loaded, so single-route users keep today's one-click path. The level appears only when it can actually narrow something.
• Failure rows (state.failures) stay visible at the provider level, where they belong, instead of being appended after every model.

2. A direct reasoning-effort slider

Effort is a small, ordered, per-model set of levels, so it deserves a control that shows the whole range at once instead of a nested list that closes the menu on pick. A discrete slider in the effort pane, stepping over exactly the adapter-advertised levels (reasoning.efforts, plus the provider-default choice when reasoning.defaultEffort is absent), makes the trade-off visible and adjustable in one gesture.

This is the same ask as #6086 Direct reasoning-effort slider beside the composer model selector, which already carries a complete implementation, coverage and browser scenarios — this post is not a competing proposal for it; treat #6086 as the implementation of record. The only addition here is one requirement: keep the existing level list in the pane as an equivalent entry. A slider is fast for adjacent steps but poor for jumping straight to an extreme, and the list is the established, accessible, testable path. Both should drive the same select({ provider, model, reasoningEffort }) call.

Behavior

Verifiable acceptance criteria, all client-side:

1. With two or more providers loaded, the Model cell opens a provider list; choosing a provider opens only that provider's models; Back returns to the provider list and restores focus to the cell that opened it.
2. With exactly one provider loaded, no provider level appears and the model list opens directly, as today.
3. The model in use is checked in both levels; the provider row of the current selection carries the checked state.
4. ↑/↓ move focus within the pane shown; Tab settles the focused row; Escape and Shift+Tab leave a drilled pane first (model → provider → root) and otherwise close to the trigger.
5. Selecting a model still submits the complete provider + model (+ optional reasoningEffort) selection through the existing session.selectModel path; no new Remote call, no change to stored ids or to session logs.
6. The effort pane offers a discrete slider over the model's advertised levels and still offers the same levels as a list; both submit the same selection, and the pending state keeps focus and shows the existing spinner.
7. A model without reasoning metadata shows neither a slider nor an Effort row, matching today's behavior.
8. An unroutable or failed provider group stays visible and unselectable, and does not block the other providers.
9. Existing keyboard, focus-restoration, pending-selection and rejected-selection behavior is unchanged, and the new panes stay reachable and testable under the existing role="menu" / menuitemradio / aria-checked contract.

Implementation boundary

Pure presentation over the per-session directory that already exists: ctx.modelDirectories (ModelDirectoryResolver → ModelDirectory) already publishes groups[].id/name/models[] with per-model reasoning.defaultEffort / reasoning.efforts[], and already owns submission and the pending/error state shared with the /model popup. The change is local to:

• packages/client/ui-model-selection/src/client/ModelSelect.tsx — the provider pane, the narrowed model pane, the effort slider
• packages/client/ui-model-selection/src/client/ModelSelect.module.css — the provider rows and slider track
• packages/client/ui-model-selection/src/client/locales.ts — bilingual keys for the provider level and the slider's accessible name

No host-side change, no new RPC, no persistence change: selection and durability keep using provider/model/effort ids. The /model popup shares the same directory and can adopt the provider level in a follow-up.

Design questions for the team

• Should provider-first be the default structure, or an opt-in for catalogs above some size? The single-provider collapse above makes it a no-op for simple setups, which is why I lean default.
• Placement of the effort slider: inside the effort pane as proposed, or beside the model control as in #6086? Either is fine; the pane keeps the composer's one-line width behavior untouched.
• Whether provider matching should also be reachable by typing (i.e. merge the search field and the provider level into one flow). This is complementary to the search proposals rather than in conflict with them.

I have verified the composer seat, the slot contract (conversation.input.model as a single slot with priority shadowing), and the directory service on 0.1.7-rc.2; the two changes are presentation-only against those. Happy to prepare a patch for review if the direction is useful — noting #3147 and #4842 both hit the closed-PR policy, so I am posting here first.

中文摘要

问题：输入框右侧的模型菜单把每个提供方的分组标题和全部模型铺在同一层滚动列表里。分组只是标题，不是一个能进入的层级，所以模型越多、提供方越多，找起来越慢——单个 OpenRouter 会话就有 276 个模型（见 #2352 的确认评论），本机 0.1.7-rc.2 配置下同一层里也有四个以上提供方分组。推理等级还要再钻一层，且选中后菜单即关闭。

建议一：先选提供方，再选模型。把 model 面板做成两级：先列出提供方（名称、模型数量、当前标记），进入后只显示该提供方的模型，并提供返回行。这正是菜单已有的 Model/Effort 钻取模式，只是多一层，不引入新的交互范式。当只加载了一个提供方时自动折叠该层级，单路由用户保持现在的一步直达。若要查的是「某个路由」，而不知道它下面哪个 id 是当前模型，搜索帮不上忙——这也是它与 #2352、#4211、#4842、#5122 的搜索建议互补、而非重复的原因。

建议二：推理等级用滑块。档位是每模型的小而有序的集合，适合一次看全、一次调整。此点与 #6086 相同，#6086 已附完整实现，应作为该功能的落地实现，本贴不与之竞争；唯一补充诉求是保留原档位列表作为等价入口（滑块适合相邻档位微调，列表适合直接跳到极端档，且列表是既有、可测、无障碍的路径），两者调用同一个选择提交。

改动边界：纯客户端呈现。数据与提交沿用既有的每会话 ModelDirectory（ctx.modelDirectories），它已提供 groups[].id/name/models[] 与每模型的 reasoning.defaultEffort / reasoning.efforts[]，并与 /model 弹窗共用 pending/错误状态。仅涉及 ModelSelect.tsx、ModelSelect.module.css、locales.ts，无 Host 改动、无新增 RPC、无持久化变更。

验收：多提供方时出现提供方层级并可返回；单提供方时折叠；当前模型与当前提供方在两个层级都有勾选；↑↓/Tab/Escape/Shift+Tab 维持既有面板契约；提交仍走 session.selectModel 且 id 与日志不变；无推理元数据的模型不显示滑块与 Effort 行；失败的提供方分组可见但不可选且不影响其他分组；无障碍 menu/menuitemradio/aria-checked 契约保持。

[codeOct]

Note on scope and overlap, so this does not read as a duplicate of existing posts:

• Search/filter proposals (#2352, #4211, #4842, #5122) solve a different half of the problem: they assume you can name the model. Provider-first assumes you know the route you want but not which of its ids is current — the common case when one route alone serves 276 models. They compose well: a provider level plus a search field is strictly better than either alone.
• The effort slider is #6086, which already has a full implementation and browser coverage. I do not propose a competing implementation; I added a comment there asking only that the existing level list remain available next to the slider as an equivalent entry, and I treat that post as the implementation of record.
• Model picker filtering and bulk selection #3147 targets the Settings model-candidate picker, not the per-session composer seat.

So the genuinely new ask here is the first one: make the provider a level you enter rather than a heading you scroll past, with the level collapsing back to today's path when only one provider is loaded. The rest is deliberately deferred to the posts that already own it.

中文摘要：说明与本贴相关的既有提案分工，避免被当作重复帖——#2352/#4211/#4842/#5122 解决的是「已知道模型名」的搜索场景；本贴解决的是「只知道自己想要哪个路由、但不知道其下哪个 id 是当前模型」的场景（单路由 276 个模型时很常见），两者可叠加。滑块部分以 #6086 为实现归属，我仅在其下评论请求保留原档位列表，不另起实现。#3147 针对设置页的候选选择器，非本会话 composer 座位。因此本贴真正新增的诉求只有「把提供方做成可进入的层级，且仅一个提供方时折叠回现状」。