[Feature Proposal] Direct reasoning-effort slider beside the composer model selector

[foo-hao]

Direct reasoning-effort slider beside the composer model selector

Use case

When switching between routine and reasoning-heavy tasks, adjusting effort through the composer menu takes several interactions. A directly visible discrete slider makes the available effort choices easier to reach.

Implementation

A focused implementation against public master b2e3b2a (v0.1.5-alpha.2) is available:

• Implementation commit
• Review branch

The slider sits beside the model control and uses the exact advertised effort choices and labels, including the provider-default choice when available. It appears when there are at least two choices. The existing model menu continues to offer its current selection workflow.

Pointer drags preview locally and commit once on release; cancellation discards the preview. Keyboard navigation uses the native range control, including Home and End. A pending selection keeps keyboard focus while further changes wait for completion. Locked input disables the control. Model changes reset the local drag, the Host remains authoritative, and rejected selections use the existing error feedback.

Validation

• The 34-test model-selection package run passed with 100% statements, branches, functions and lines for the new slider component.
• Two further integration cases covered absent reasoning metadata and locked/rejected selection; the resulting 10-case model-control suite passed.
• Four real-browser scenarios passed, covering the existing menu, keyboard focus, provider-default restoration, settings persistence, and pointer preview followed by release-time persistence.
• Full build, repository lint, 34 documentation checks, staged checks and the pre-push typecheck passed.
• Paired English/Chinese documentation and a decision record accompany the patch.

Design feedback

Would a direct effort control fit the intended composer design? The implementation keeps the existing model-selection owner and submission callback. Feedback on placement, compact-width behavior, or a preferred extension contract would help align the contribution with the team's direction.

中文摘要

为输入框模型选择器旁增加直接可见的离散推理等级滑块，严格复用适配器公布的档位和名称。拖动先预览、松开后提交；键盘可直接调整，并在等待响应时保留焦点。现有模型菜单继续可用。实现已完成单元、覆盖率、真实浏览器、构建、类型与文档验证，欢迎团队对布局和集成方式提出意见。

[codeOct]

Supporting this — the composer effort control should show the whole ordered range at once rather than a nested list that closes the menu on pick.

One requirement worth folding into the implementation, from a related proposal I posted in #7942: keep the existing level list in the effort pane as an equivalent entry next to the slider. A discrete slider is fast for adjacent steps but poor for jumping straight to an extreme, and the list is the established, accessible, already-tested path. Both should drive the same select({ provider, model, reasoningEffort }) call, with the pending state keeping focus and showing the existing spinner. A model without reasoning metadata should still show neither control.

The other half of #7942 is independent of this and does not overlap it: the model pane becomes two levels (provider, then that provider's models), collapsing to today's one-click path when only one provider is loaded.

中文摘要：支持此提案——推理等级应一次展示完整有序档位，而不是选中即关闭的嵌套列表。建议补充一点：滑块旁保留原档位列表作为等价入口（滑块适合相邻微调，列表适合直达极端档，且已是既有、可测、无障碍的路径），两者调用同一提交。无推理元数据的模型两者都不显示。另一条 #7942 与本提案不重叠：模型面板改为两级（先提供方、再其模型），只加载一个提供方时自动折叠为现状。

[foo-hao]

Thanks @codeOct — agreed that the existing level list should remain an equivalent entry.

The linked implementation already retains that list in the Effort pane. The composer slider and the list use the same chooseEffort helper and select({ provider, model, reasoningEffort }) callback, including the provider-default choice. Both use the selected model’s advertised metadata; a model without reasoning metadata shows neither control. The slider additionally requires at least two available choices.

The current layout puts the slider beside the composer model selector and keeps the list in its existing pane. Placing both together inside the Effort pane is a useful design question while retaining both entry points. I also checked current master: its pending state, spinner, and selection-result contract have evolved since the linked branch’s base. Refreshing the patch should follow that current API and preserve focus during submission. The original branch covers slider focus retention; the newer spinner behavior still needs that adaptation.

The provider-first navigation in #7942 is a separate improvement that can compose with this effort control.

中文：同意保留原档位列表作为等价入口。现实现已保留列表，两者共用同一提交与适配器元数据；当前滑块在模型按钮旁，列表在原 Effort 面板。刷新补丁时应适配最新主线的 pending、加载反馈和提交返回值，并验证等待期间的焦点行为。#7942 的提供方分层可以与此功能配合。