Skip to content

runWithModelFallback() treats LiveSessionModelSwitchError as candidate_failed, causing unnecessary fallback chain #57471

Description

@yuxiaoyang2007-prog

Summary

When a live session model switch is active (e.g., session locked to openai-codex/gpt-5.4), every request that initially targets a different model (e.g., minimax-cn/MiniMax-M2.7-highspeed for compaction) triggers the entire fallback chain of 12+ candidates before finally reaching the locked model. This adds 20-30 seconds of wasted time per request.

Root Cause

runWithModelFallback() catches LiveSessionModelSwitchError and records it as candidate_failed, then proceeds to try the next candidate. Since the session is locked to a specific model, every candidate except the locked one will fail with the same error.

The actual meaning of LiveSessionModelSwitchError is "redirect this request to the session's locked model", not "this candidate has failed".

Observed Behavior

Requested: minimax-cn/MiniMax-M2.7-highspeed (compaction model)
Session locked to: openai-codex/gpt-5.4

Fallback chain (all rejected with "Live session model switch requested"):
  1. minimax-cn/MiniMax-M2.7-highspeed  → candidate_failed
  2. google/gemini-3-flash-preview       → candidate_failed
  3. deepseek/deepseek-chat              → candidate_failed
  4. dashscope/qwen3.5-plus              → candidate_failed
  5. bailian/qwen3.5-plus                → candidate_failed
  6. openai-codex/gpt-5.2                → candidate_failed
  7. arc-codingpln/ark-code-latest       → candidate_failed
  8. openai-codex/gpt-5.3-codex-spark    → candidate_failed
  9. google/gemini-3.1-pro-preview       → candidate_failed
  10. zai/glm-5-turbo                    → candidate_failed
  11. openai-codex/gpt-5.4-mini          → candidate_failed
  12. openai-codex/gpt-5.3-codex         → candidate_failed
  13. openai-codex/gpt-5.4               → candidate_succeeded ✓

186 [ws-stream] WebSocket connect failed warnings logged in a single day due to repeated fallback attempts.

Expected Behavior

When runWithModelFallback() encounters a LiveSessionModelSwitchError:

  1. Read the target provider/model from the error
  2. If the target is already in the candidate list, jump directly to that candidate
  3. If not, insert it at the front and retry immediately
  4. Record the event as live_session_redirect, not candidate_failed

This would reduce the chain from:

minimax → gemini → deepseek → ... (12 failures) → gpt-5.4

to:

minimax → gpt-5.4

Environment

  • OpenClaw v2026.3.28
  • Primary model: openai-codex/gpt-5.4 (ChatGPT OAuth)
  • Compaction model: minimax-cn/MiniMax-M2.7-highspeed
  • Platform: macOS (Darwin, ARM64)

Notes

  • The fallback mechanism itself is correct and should not be disabled — it handles real failures (rate limits, auth errors, provider outages).
  • The issue specifically affects internal operations (compaction, heartbeat) that use a different model than the session's locked model.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

Priority

None yet

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions