Title

[openclaw status] Model field should distinguish base model from active fallback

Summary

When a session's primary model fails and a fallback is used, session_status and openclaw status --json report only the active (fallback) model. This makes it appear as if the configured primary has been replaced, which can cause confusion or look like a routing policy violation when one isn't intended.

Environment

• OpenClaw 2026.6.1 (2e08f0f)
• gateway 8h+ uptime
• Agent: main (also telegram, ocr)
• Default primary: minimax/MiniMax-M3
• Fallbacks: ollama/qwen3.5-codgician-q4km, ollama/qwen3.6-blue:35b-a3b

Reproduction

1. Set primary = minimax/MiniMax-M3, fallbacks = ollama/qwen3.5-codgician-q4km, ...
2. Make primary model return a transient error (e.g., 529 overloaded)
3. OpenClaw falls back to next model in chain
4. Run session_status

Current behavior

🧠 Model: openai/gpt-5.5   ← active fallback shown
🔄 Fallbacks: openai/gpt-5.5, ollama/...
⚙️ Runtime: OpenAI Codex

openclaw status --json sessions.recent[0]:

{
  "model": "MiniMax-M3",                ← raw
  "configuredModel": "minimax/MiniMax-M3",
  "selectedModel": "openai/gpt-5.5",    ← active fallback
  "modelSelectionReason": null,         ← missing reason
  ...
}

The base/active separation exists in --json output but the human-readable status card collapses both into a single Model: line, hiding the configured primary.

Expected behavior

The status card should show both base and active, plus why the fallback was selected. Example:

🧠 Model (base):    minimax/MiniMax-M3
🧠 Model (active):  ollama/qwen3.6-blue:35b-a3b
🔁 Fallback reason: minimax returned 529 overloaded (23:32:02 KST)
🔄 Remaining fallbacks: ollama/qwen3.5-codgician-q4km

Or a single line if no fallback is in use:

🧠 Model: minimax/MiniMax-M3

Why this matters

• Operators can't tell at a glance whether a session is on its configured model or a fallback
• A fallback that triggers automatically can look like a policy violation in audit logs
• Debugging model routing issues is harder without knowing why a fallback was chosen
• The underlying data (configuredModel / selectedModel / modelSelectionReason) is already there, just not surfaced in the status card

Suggested fix

In the status card formatter, when selectedModel != configuredModel:

• Show both fields explicitly
• Surface modelSelectionReason (currently null — populate when fallback is selected)
• Keep the existing Fallbacks: line for the chain

Severity

Low (cosmetic / observability), but high value for operators who manage multi-model setups.

Related

• agents.defaults.model.fallbacks chain config
• agents.list[].model.fallbacks per-agent overrides
• modelSelectionReason field in sessions.recent[] (currently always null)