Summary

• Problem: The openclaw status Overview "Sessions" row always displayed the statically configured model (e.g. gemini-pro) even when a fallback was active and the agent was actually using a different model (e.g. gemini-flash). The per-session table below it already showed the correct model, creating a confusing mismatch.
• Why it matters: Users relying on /status to verify which model is in use during a fallback received incorrect information in the most prominent overview line.
• What changed: status.command.ts now resolves activeModel as summary.sessions.recent[0]?.model ?? defaults.model ?? \"unknown\" — preferring the most recent session's runtime model (already correctly written to the session store after every run, including fallback runs) over the static configured default.
• What did NOT change: The per-session table, resolveSessionModelRef, the session store write path, model-fallback.ts, status.summary.ts, and all types are untouched. This is a pure display fix in the overview row.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• UI / DX

Linked Issue/PR

• Closes [Bug]: /status displays session-configured model instead of actual routed model after fallback #23830

User-visible / Behavior Changes

The Sessions line in openclaw status Overview now shows the model currently in use (fallback or primary) rather than always showing the configured default model.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: Any
• Runtime/container: Node 22+
• Model/provider: Any provider with fallbacks configured

Steps

1. Configure a model with fallbacks (e.g. agents.defaults.model.primary: gemini-pro, fallbacks: [gemini-flash])
2. Trigger a rate-limit or quota error so the fallback activates
3. Run openclaw status

Expected

• Overview Sessions row shows gemini-flash (the actual model in use)

Actual (before fix)

• Overview Sessions row showed gemini-pro (the configured default) while the per-session table below correctly showed gemini-flash

Evidence

• Failing test/log before + passing after — added "shows actual session model in overview row when it differs from configured default" test in src/commands/status.test.ts; all 8 tests pass

Human Verification (required)

• Verified scenarios: unit test mocking a session entry with model: "google:gemini-flash" while config default differs — overview row correctly shows gemini-flash
• Edge cases checked: no sessions (falls back to defaults.model), session with null model (falls back to defaults.model), session with matching model (no visible change)
• What you did not verify: live end-to-end with a real provider quota exhaustion

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert the single-line change in status.command.ts (restore defaults.model in the Sessions overview row)
• Files/config to restore: src/commands/status.command.ts
• Known bad symptoms reviewers should watch for: None — this is a read-only display change

Risks and Mitigations

• Risk: If a session entry has a stale/incorrect model field, the overview row would show it. Mitigation: This was already the case for the per-session table; the session store write path (persistSessionUsageUpdate) always records the actual model used, so stale values are only possible if the session never ran a successful turn.

Greptile Summary

Fixed the /status overview row to show the actual runtime model (including fallbacks) instead of always showing the configured default model. The implementation correctly uses summary.sessions.recent[0]?.model with proper fallback chain to defaults.model and then "unknown".

• Changed status.command.ts:268 to resolve activeModel from most recent session's model field
• Updated display label from "default" to "model" in Sessions overview row (status.command.ts:385)
• Added test case verifying the fix when session model differs from configured default
• Updated CHANGELOG.md with user-facing fix description

The change is minimal, focused, and aligns with the existing data flow where session entries already store the runtime model (populated during execution including fallback scenarios).

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The change is a focused display fix with proper fallback handling. The test coverage validates the new behavior, the implementation correctly uses optional chaining with fallback to defaults, and the change aligns with how session model data is already populated during runtime (including fallback scenarios). No logic paths were modified beyond the single display variable assignment.
• No files require special attention

_{Last reviewed commit: d009211}