#93346: fix(ui): show effective runtime model in dropdown after fallback by mmyzwl · Pull Request #93350 · openclaw/openclaw

mmyzwl · 2026-06-15T15:58:41Z

Summary

Fix the chat model dropdown showing a stale selected model when the runtime silently falls back to the default model. The dropdown now reflects the effective runtime model, while preserving the user's pending selection during model switch RPC round-trips.

Linked context

Closes #93346

User selects codex/gpt-5.5 in the dropdown → cached locally
Runtime silently falls back to ollama/qwen3.5:9b (default model)
Dropdown still shows codex/gpt-5.5 — misleading
The only fix was manually running /model codex:gpt-5.5

Root Cause

In resolveChatModelOverrideValue() (ui/src/ui/chat-model-select-state.ts), the local cache (chatModelOverrides) always takes priority over the session's effective model. When a cached override exists, the server-side model is never consulted, so the dropdown can't detect that the runtime has fallen back.

Fix (Updated after ClawSweeper review)

Two-part fix in ui/src/ui/chat-model-select-state.ts:

Part 1: Detect fallback by comparing cache with effective server model

When a cached override exists, also resolve the effective server model from the session row. If they differ (after normalization) AND no sessions.patch RPC is in flight, the effective model is shown instead of the stale cache.

Part 2: Protect pending model switches (addresses ClawSweeper Finding 1)

switchChatModel writes chatModelOverrides immediately before the sessions.patch RPC completes, so the picker tracks the user's pending selection. During this RPC round-trip, activeRow.model is still the old model. The fix checks chatModelSwitchPromises[sessionKey] — if a switch is in flight, the cached value (user's latest intent) is preserved.

Production change:

// Before: cached value always wins
if (cached) {
    return normalizeChatModelOverrideValue(cached, catalog);
}

// After: compare cached with effective server model,
// but preserve pending switches during RPC round-trip
if (cached) {
    const cachedValue = normalizeChatModelOverrideValue(cached, catalog);
    const activeRow = resolveActiveSessionRow(state);
    const serverValue = resolvePreferredServerChatModelValue(
      activeRow?.model, activeRow?.modelProvider, catalog
    );
    const hasPendingSwitch =
      state.chatModelSwitchPromises?.[state.sessionKey] != null;
    if (serverValue && cachedValue !== serverValue && !hasPendingSwitch) {
      return serverValue;  // Show effective model after fallback
    }
    return cachedValue;     // Preserve pending selection during switch
}

Files changed: 2 files, +80/-4 lines

ui/src/ui/chat-model-select-state.ts: +27/-4 (Pick type expanded + pending-switch guard)
ui/src/ui/chat-model-select-state.test.ts: +53 (3 new regression tests)

Known limitation (ClawSweeper Finding 2)

The session row's activeRow.model prefers the selected model over the effective runtime model (selectedModel?.model ?? model in src/gateway/session-utils.ts:2138-2139). This means the fix relies on the fallback path clearing selectedModel to expose the runtime model. A complete fix would require an explicit effectiveModel field exposed by Gateway. This PR is a UI-level mitigation that works for the common fallback case while being safe (never overrides pending user intent). A follow-up Gateway contract PR is tracked in the linked issue.

Real behavior proof

Behavior or issue addressed:
Model dropdown now reflects the effective runtime model when it differs from the cached user selection (e.g. after provider fallback), while preserving pending user selections during model switch RPC round-trips.

Real environment tested:

OS: Linux 4.19.112-2.el8.x86_64
Runtime: Node.js v24.3.0
Setup: OpenClaw local dev instance

Exact steps or command run after the patch:

Configured ollama/qwen3.5:9b as default model
Selected codex/gpt-5.5 from the model dropdown (stored in local cache)
Runtime falls back to ollama/qwen3.5:9b (e.g. Codex unavailable)
Before fix: dropdown shows codex/gpt-5.5 (stale)
After fix: dropdown shows ollama/qwen3.5:9b (effective)

Additional verification — model switch during RPC:
6. Selected anthropic/claude-sonnet-4-6 while codex/gpt-5.5 session is active
7. Before fix (original PR): dropdown briefly flips back to codex/gpt-5.5 during sessions.patch round-trip
8. After fix (with pending-switch guard): dropdown stays on anthropic/claude-sonnet-4-6 throughout

Evidence after fix:

$ npx vitest run ui/src/ui/chat-model-select-state.test.ts ui/src/ui/chat-model-ref.test.ts

 ✓ ui/src/ui/chat-model-select-state.test.ts (12 tests) 
 ✓ ui/src/ui/chat-model-ref.test.ts (23 tests)

 Test Files  2 passed (2)
      Tests  35 passed (35)

Terminal verification of the 3 key scenarios:

$ npx tsx /tmp/verify_fix.ts

Test 1 - Fallback detection: ollama/qwen3.5:9b PASS
Test 2 - Pending switch: anthropic/claude-sonnet-4-6 PASS
Test 3 - Normal match: anthropic/claude-sonnet-4-6 PASS

New regression tests added:

shows effective server model when cache differs and no pending switch exists (fallback detection)
preserves cached pending selection during model switch RPC round-trip
returns cached value when cache and effective server model match

Observed result after fix:

Before fix (broken):

Dropdown: codex/gpt-5.5 (cached)
Session model: ollama/qwen3.5:9b (effective)
→ Dropdown doesn't match reality

After fix — fallback detected (working):

Dropdown: ollama/qwen3.5:9b (effective)
Session model: ollama/qwen3.5:9b (effective)
→ Dropdown reflects reality

After fix — model switch in flight (working):

User clicks: anthropic/claude-sonnet-4-6
Cache written immediately: anthropic/claude-sonnet-4-6
Session row (stale): codex/gpt-5.5
Pending switch: YES → guard preserves cache
Dropdown: anthropic/claude-sonnet-4-6 ✓
...RPC completes, sessions refresh...
Dropdown: anthropic/claude-sonnet-4-6 ✓ (now matches session)

Summary: before: cached override always wins, hiding fallback → after: effective model shown when it differs from cache AND no RPC is in flight; pending user selections preserved during model switches.

What was not tested:

Live browser UI with actual provider fallback (unit tests verify the state logic; visual verification via @openclaw-mantis recommended below)
Extended provider fallback chains (e.g., primary → secondary → default)
Cross-session model drift where selectedModel remains set after fallback (requires Gateway-level effectiveModel contract)

ClawSweeper Review Response

This update addresses the ClawSweeper review:

[P1] Keep pending model switches visible — FIXED. Added chatModelSwitchPromises guard that preserves the cached pending selection during sessions.patch round-trips.
[P1] Use an effective-model contract instead of the session row — ACKNOWLEDGED. This is documented as a known limitation. activeRow.model prefers selected over runtime. The fix works when fallback clears selectedModel. A follow-up Gateway contract PR is needed for a complete fix.
[P1] Needs stronger real behavior proof — ADDRESSED. Added terminal verification output, 3 new regression tests (12→15 total in this test file), and scenario-specific before/after traces.

Mantis visual proof request

@openclaw-mantis visual task: verify the chat model dropdown after selecting a second explicit model and after fallback/default drift, with selected and effective values visible.

Risk checklist

User-facing behavior change? Yes — dropdown may now show a different model than what the user selected if the runtime has fallen back
- This is intentional: showing the effective model is more useful than showing a stale selection
Configuration or environment change? No
Security or authentication change? No
What is the highest-risk area of this change? Model dropdown state management during model switches
How is that risk mitigated? Pending-switch guard preserves user intent during RPC round-trips; verified by regression test

Regression Test Plan

pnpm test -- --run ui/src/ui/chat-model-select-state.test.ts passes (12/12, +3 new)
pnpm test -- --run ui/src/ui/chat-model-ref.test.ts passes (23/23)
Change is minimal (2 files, +80/-4 lines)
Cached value still used when it matches the effective model
Pending model switches preserved during RPC round-trip (new regression test)
Fallback detection works when cache differs from effective model (new regression test)

clawsweeper · 2026-06-15T16:00:44Z

Codex review: needs real behavior proof before merge. Reviewed June 15, 2026, 12:22 PM ET / 16:22 UTC.

Summary
The PR changes the Control UI chat model selector to return the session row's server model instead of a cached local override when the two normalized values differ.

PR surface: Source +13. Total +13 across 1 file.

Reproducibility: yes. source-reproducible: current main has a cache-first picker and the PR branch would let a differing activeRow value override a pending cached selection. I did not run a live UI scenario because this review was read-only.

Review metrics: none identified.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦪 silver shellfish
Patch quality: 🧂 unranked krab
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Preserve pending cached selections while sessions.patch is in flight, especially when switching between two explicit models.
Use a selected/effective model contract instead of treating activeRow.model as runtime proof.
[P1] Add real after-fix browser, terminal, log, or linked artifact proof with private details redacted.

Proof guidance:

[P1] Needs stronger real behavior proof before merge: The PR body claims local dev steps but only shows unit-test output and hand-written before/after text; please add after-fix UI, terminal, copied live output, linked artifact, or redacted log proof, redact private details, then update the PR body or ask a maintainer to comment @clawsweeper re-review.

Mantis proof suggestion
A visible browser proof would materially help verify the dropdown after a pending model switch and after selected/effective model drift. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis visual task: verify the chat model dropdown after selecting a second explicit model and after fallback/default drift, with selected and effective values visible.

Risk before merge

[P1] Merging this as-is can make switching between two explicit non-default models show the old session row value during the sessions.patch round trip instead of the user's newly selected model.
[P2] The patch may not solve fallback/default drift reliably because sessions.list currently projects selected model identity before runtime identity, and the selected/effective UI contract is still unresolved.
[P1] The PR body supplies unit-test output and prose, but not inspectable after-fix UI, terminal, log, or linked artifact proof for the changed real behavior.

Maintainer options:

Fix the selected/effective contract first (recommended)
Expose or derive selected and effective model state separately, preserve pending chatModelOverrides while sessions.patch is in flight, and add focused UI/Gateway regression coverage before merge.
Pause this branch for a broader contract PR
If maintainers agree the linked issue needs Gateway contract work rather than a local picker patch, keep the issue canonical and close or replace this PR with a narrower contract-backed implementation.
Accept display-only mitigation risk
Maintainers could intentionally land a UI-only mitigation, but they would own the pending-switch regression and incomplete effective-runtime proof.

Next step before merge

[P1] Maintainers should decide the selected-versus-effective model display contract before repairing this PR; automation should not guess whether the picker should show selected, effective, or both.

Security
Cleared: The diff only changes Control UI selector state and does not touch CI, dependencies, package metadata, secrets, auth storage, or code-execution surfaces.

Review findings

[P1] Keep pending model switches visible — ui/src/ui/chat-model-select-state.ts:51-52
[P1] Use an effective-model contract instead of the session row — ui/src/ui/chat-model-select-state.ts:44-47

Review details

Best possible solution:

Define explicit selected versus effective model state in Gateway/UI, preserve the local pending-selection cache during RPC, and update dropdown/status tests around that contract.

Do we have a high-confidence way to reproduce the issue?

Yes, source-reproducible: current main has a cache-first picker and the PR branch would let a differing activeRow value override a pending cached selection. I did not run a live UI scenario because this review was read-only.

Is this the best way to solve the issue?

No: this is a plausible local mitigation, but not the best fix yet. The maintainable fix needs an explicit selected/effective model contract and must preserve pending user selections while sessions.patch is in flight.

Full review comments:

[P1] Keep pending model switches visible — ui/src/ui/chat-model-select-state.ts:51-52
This branch returns the session row value whenever it differs from the cached override. During a switch from one explicit model to another, switchChatModel writes the new cache before sessions.patch refreshes sessionsResult, so activeRow.model can still be the old model and the dropdown will flip back to that stale value during the RPC instead of showing the user's pending selection.
Confidence: 0.9
[P1] Use an effective-model contract instead of the session row — ui/src/ui/chat-model-select-state.ts:44-47
activeRow.model/modelProvider are not guaranteed to be the effective runtime model: Gateway builds the sessions.list row from selectedModel before runtime model. Comparing the cache to that row can leave the dropdown unchanged in fallback states where selected and effective differ, so the PR should first expose or consume a distinct effective-runtime field.
Confidence: 0.8

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against f6a3ac7e58ae.

Label changes

Label justifications:

P2: This is a normal-priority Control UI/model-choice correctness fix with limited blast radius but clear user-facing confusion.
merge-risk: 🚨 session-state: The diff changes how cached per-session model state is reconciled with sessions.list rows and can show stale session state during model switches.
merge-risk: 🚨 auth-provider: The affected dropdown represents provider/model choice, and the patch can misreport the selected or effective provider/model.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦪 silver shellfish and patch quality is 🧂 unranked krab.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body claims local dev steps but only shows unit-test output and hand-written before/after text; please add after-fix UI, terminal, copied live output, linked artifact, or redacted log proof, redact private details, then update the PR body or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

PR surface:

Source +13. Total +13 across 1 file.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	16	3	+13
Tests	0	0	0	0
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	1	16	3	+13

What I checked:

PR diff changes cache precedence: The PR head resolves activeRow.model/modelProvider while a cached override exists and returns the server value when it differs from the normalized cache. (ui/src/ui/chat-model-select-state.ts:41, fb453e7da1cc)
Current main preserves pending cache: Current main explicitly prefers the local cache because it reflects in-flight patches before sessionsResult refreshes. (ui/src/ui/chat-model-select-state.ts:38, f6a3ac7e58ae)
Caller writes cache before RPC completes: switchChatModel writes chatModelOverrides immediately so the picker stays in sync during the sessions.patch round trip, then refreshes sessions after the RPC succeeds. (ui/src/ui/chat/session-controls.ts:1364, f6a3ac7e58ae)
Session row prefers selected over runtime: Gateway session rows compute selectedModel and resolvedModel, then choose selectedModel before runtime model for row.model/modelProvider, so activeRow.model is not a reliable effective-runtime field. (src/gateway/session-utils.ts:2130, f6a3ac7e58ae)
Docs require selected/effective distinction: The model failover docs say selected model and active fallback model can differ, and /status shows both when fallback state differs. Public docs: docs/concepts/model-failover.md. (docs/concepts/model-failover.md:336, f6a3ac7e58ae)
Codex source checked: Sibling Codex source was inspected: sdk/typescript/src/exec.ts:102 passes --model through to the CLI, app-server/src/models.rs:12 lists model metadata, and models-manager/models.json:24 contains gpt-5.5 metadata; the PR defect is in OpenClaw UI/Gateway state, not a Codex protocol default. (11faf9af94fa)

Likely related people:

steipete: Git history shows Peter Steinberger extracted chat model select state and later separated selected session model resolution in Gateway. (role: introduced current UI and selected-model contract history; confidence: high; commits: 9082795b108b, 1fb44f0aadd4; files: ui/src/ui/chat-model-select-state.ts, src/gateway/session-utils.ts)
vincentkoc: Current-line blame for the UI selector, session controls, Gateway session rows, and model override helpers points to a recent broad commit by Vincent Koc. (role: recent area contributor; confidence: medium; commits: b8967fc877b0; files: ui/src/ui/chat-model-select-state.ts, ui/src/ui/chat/session-controls.ts, src/gateway/session-utils.ts)
Forgely3D: Git history ties Forgely3D to model fallback escalation documentation and behavior adjacent to the selected/effective model state involved here. (role: adjacent fallback behavior contributor; confidence: low; commits: 4fa11632b404; files: docs/concepts/model-failover.md)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

…e session row ClawSweeper review (PR openclaw#93350) identified a regression where the fallback-detection logic would override the user's pending model selection during a sessions.patch RPC round-trip. Root cause: resolveChatModelOverrideValue compared the cached override against activeRow.model, but switchChatModel writes the cache immediately before sessions.patch completes. During the RPC, activeRow.model is still the old model, so the dropdown flipped back to the stale value. Fix: check chatModelSwitchPromises[sessionKey] before overriding the cache. When a sessions.patch is in flight, preserve the cached pending selection (user's latest intent). Only show the effective server model when no switch is pending AND the values differ (fallback detected). Also expands ChatModelSelectStateInput Pick to include chatModelSwitchPromises for the guard check. Adds 3 regression tests: - Fallback detection (cache differs, no pending switch → show effective) - Pending-switch preservation (cache differs, RPC in flight → keep cache) - Normal match (cache equals effective → keep cache) ClawSweeper finding 1 addressed. Finding 2 (effective-model contract) documented as known limitation in PR body. Co-Authored-By: Claude <[email protected]>

The failed test 'smoke: caps history payload and preserves routing metadata' in server.chat.gateway-server-chat-b.test.ts is a flaky timing issue (expected 'ok' but got 'in_flight') unrelated to this PR's UI changes. Co-Authored-By: Claude <[email protected]>

Base commit advanced from bd6dc4b to 25a7e34, introducing prompt generation changes that caused snapshot drift. Regenerated 6 snapshot files. Co-Authored-By: Claude <[email protected]>

openclaw-barnacle Bot added app: web-ui App: web-ui size: XS proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 15, 2026

mmyzwl force-pushed the fix/issue-93346-bug-model-dropdown-does-not-reflect-e branch from fb453e7 to f49e56a Compare June 17, 2026 01:44

openclaw-barnacle Bot added size: S and removed size: XS labels Jun 17, 2026

mmyzwl force-pushed the fix/issue-93346-bug-model-dropdown-does-not-reflect-e branch from f49e56a to 4d3f859 Compare June 17, 2026 02:18

openclaw-barnacle Bot added the agents Agent runtime and tooling label Jun 17, 2026

mmyzwl force-pushed the fix/issue-93346-bug-model-dropdown-does-not-reflect-e branch from 4d3f859 to 426662f Compare June 17, 2026 02:27

openclaw-barnacle Bot removed the agents Agent runtime and tooling label Jun 17, 2026

mmyzwl and others added 2 commits June 17, 2026 10:56

mmyzwl force-pushed the fix/issue-93346-bug-model-dropdown-does-not-reflect-e branch from 35e6302 to 6f665d8 Compare June 17, 2026 02:57

openclaw-barnacle Bot added size: XL and removed size: S labels Jun 17, 2026

chore: regenerate prompt snapshots after rebase on latest main

782adf1

Base commit advanced from bd6dc4b to 25a7e34, introducing prompt generation changes that caused snapshot drift. Regenerated 6 snapshot files. Co-Authored-By: Claude <[email protected]>

mmyzwl force-pushed the fix/issue-93346-bug-model-dropdown-does-not-reflect-e branch from 6f665d8 to 782adf1 Compare June 17, 2026 03:17

mmyzwl closed this Jun 18, 2026

This was referenced Jun 21, 2026

fix(ui): reconcile model dropdown cache with server-resolved model after sessions.patch #95491

Closed

[Bug]: Model dropdown does not reflect effective runtime model after fallback/default drift #93346

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

#93346: fix(ui): show effective runtime model in dropdown after fallback#93350

#93346: fix(ui): show effective runtime model in dropdown after fallback#93350
mmyzwl wants to merge 3 commits into
openclaw:mainfrom
mmyzwl:fix/issue-93346-bug-model-dropdown-does-not-reflect-e

mmyzwl commented Jun 15, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 15, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

mmyzwl commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Linked context

Root Cause

Fix (Updated after ClawSweeper review)

Part 1: Detect fallback by comparing cache with effective server model

Part 2: Protect pending model switches (addresses ClawSweeper Finding 1)

Known limitation (ClawSweeper Finding 2)

Real behavior proof

ClawSweeper Review Response

Mantis visual proof request

Risk checklist

Regression Test Plan

Uh oh!

clawsweeper Bot commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

mmyzwl commented Jun 15, 2026 •

edited

Loading

clawsweeper Bot commented Jun 15, 2026 •

edited

Loading