Allow the user to choose between model auto routing or a specific model

[jtenniswood]

Add support for selecting a specific model and level of thinking, the webui currently only shows auto routing

[jtenniswood]

Follow-up plan (research)

Root cause

The daemon backend already has everything this needs:

• CreateSessionRequest already carries provider_id / model_id / reasoning_effort (contracts/proto/mecatl/v1/harness.proto:383-429, mirrored on the HTTP surface at internal/adapter/server/http.go's createSessionBody).
• ListModels returns the full selectable inventory with a per-model reasoning capability bit and context_limit (ModelInfo, harness.proto:2132-2144).
• ForkSession.reasoning_effort gives a non-destructive mid-conversation effort change — fork the transcript onto a peer session at a new tier without losing history (ADR 0055, ADR 0068).
• CreateSessionRequest.source_session_id gives the carryover path for an actual model/provider switch (which is fixed for a session's lifetime, so switching model = new session with history carried over, cross-provider safe via session.StripProviderState).
• mecatui already implements this exact UX end to end — cmd/mecatui/ui/models.go (/models picker, restart-with-carryover) and cmd/mecatui/ui/effort.go (/effort picker, fork-resume). This is a ready-made reference implementation, not a green-field design problem.

The gap is entirely in the new Studio web client (PR #618, feat/studio-atrium, not yet merged to main):

• studio/src/app/workspace/_components/chat-input.tsx's ModelEffortSelector is vendored Atrium-prototype chrome: hardcoded MODELS/EFFORT_LEVELS arrays, not runtime.models.
• Both usages in chat-view.tsx pass onModelChange={() => {}} (a no-op), and the live-session path force-disables the control with a static modelLockedLabel={live ? "Auto-routed" : undefined} — regardless of what actually resolved.
• studio/src/lib/harness/client.ts's createHarnessSession(mode) only ever POSTs { mode }. It never sends provider_id/model_id/reasoning_effort/source_session_id, and it discards the resolved_model the daemon already echoes back on CreateSessionResponse.
• There is no forkHarnessSession client function, and no UI path that calls POST /v1/sessions/{id}/fork at all.

Everything needed to fix this is TypeScript/React work inside studio/, consuming a backend contract that is already implemented, tested, and proven out by mecatui.

Scope clarification (important, easy to conflate)

Studio's existing "Model router" settings page (model-router-section.tsx, wired to fetchHarnessRouter/saveHarnessRouter) looks related but is a different feature: per internal/app/build.go ("Subagent model router, ADR 0031, Phase 5"), that classifier routes Subagent delegation calls to a category's model, not the user's own top-level chat turn. That's the router #622 ("Setup preconfigured categories for model routing") extends.

Issue #623 is about the top-level chat session's own model — which today has no per-session override in Studio at all, live or not. Worth stating explicitly in any implementation ticket so the two don't get merged into one PR by mistake.

Design: mirror the mecatui pattern, adapted to Studio's persistent chat

1. New chat (no live session yet): the ModelEffortSelector becomes a real control backed by runtime.models (already fetched via listHarnessModels, already used by the router settings page). "Auto" is the first entry and maps to omitting provider_id/model_id/reasoning_effort entirely (empty string on the wire — the existing auto/"" convention mecatui's effort.go already uses). Picking a specific model + effort threads through to createHarnessSession.
2. Switching model/provider on a live session: provider+model are fixed for a session's lifetime (ADR 0030), so this is CreateSession with source_session_id = <old session> — the same "restart with carryover" mecatui does in restartOnModelWithCarryover (cmd/mecatui/ui/models.go:347-390). Studio should close/retire the old session id client-side the same way, and rebind the chat view to the new session id.
3. Switching effort only on a live session: use ForkSession (POST /v1/sessions/{id}/fork with reasoning_effort) so the transcript survives — the ADR 0068 "fork-resume" pattern mecatui's effort.go uses instead of a restart. This needs a new forkHarnessSession client function; no proxy change needed since studio/src/app/api/mecatl/[...path]/route.ts is already a transparent catch-all.
4. Accurate "current model" display: capture resolved_model from CreateSessionResponse/Session (already returned, currently discarded) and show the actual resolved provider/model/effort instead of a hardcoded "Auto-routed" string — mirrors how mecatui reads m.effectiveModel.ReasoningEffort for its live display rather than echoing back what it sent.
5. Capability gating: hide/disable the effort submenu for a model whose ModelInfo.reasoning == false, matching the server's own capability-gating behavior described in harness.proto:415-429 ("a model with no reasoning support drops it").

Implementation steps

1. studio/src/lib/harness/client.ts: extend createHarnessSession to accept { providerId?, modelId?, reasoningEffort?, sourceSessionId? }, POST the matching provider_id/model_id/reasoning_effort/source_session_id fields, and return the parsed resolved_model alongside the session id. Add forkHarnessSession(sourceSessionId, { title?, reasoningEffort? }) hitting POST /v1/sessions/{id}/fork.
2. studio/src/features/agent/hooks/use-agent-chat.ts: thread a model/effort selection through the one createHarnessSession("default") call site (:195), and store the returned resolved_model in chat state for display.
3. studio/src/app/workspace/_components/chat-input.tsx: replace the hardcoded MODELS/EFFORT_LEVELS with runtime.models (props already available one level up via use-harness-runtime.ts), add the "Auto" sentinel row, gate the Effort submenu on model.reasoning, and make onModelChange carry both model and effort (currently it's model-only).
4. chat-view.tsx: replace the two no-op onModelChange handlers and the hardcoded "Auto-routed" label with real state — driven by (2)'s resolved model, and dispatching either the carryover-CreateSession path (model/provider change) or the fork path (effort-only change) depending on what changed.
5. Session-list / sidebar: after a carryover switch, the new session id must replace the old one in the sidebar/URL without a jarring reload — same UX concern mecatui's restart handoff already solved (m.restartedThisRun, resetSession()).
6. Tests: protocol-layer decoder/encoder tests for the new request/response fields (mirrors the existing 26 decoder tests in src/lib/protocol), a vitest unit for the selector's capability gating, and a Playwright smoke over the fixture daemon exercising "pick a model → send → see it in resolved_model" and "change effort mid-conversation → transcript survives."

Open questions to settle before starting

• Does "Auto" need to visibly say what it resolved to (e.g. "Auto — Claude Sonnet 5"), given resolved_model is available post-create? Recommend yes — matches the honesty bar ADR 0055/0030 hold the server-side echo to.
• Should the model list in the composer be filtered to providers the current deployment actually has configured (it already is, via ListModels returning only available providers), or does Studio need a "no providers configured" empty state distinct from "auto only"? ListModelsResponse.provider_status already carries the remediation hints (ProviderStatus.hint) needed for that.
• Sequencing: this has no dependency on #622 (subagent router categories) or #619 (add/remove providers) — it can land independently. It's worth landing before Add mode controls to webui #624 ("mode controls to webui") if that work also touches the input-panel chrome, to avoid two PRs fighting over the same region of chat-input.tsx.

[jtenniswood]

Done