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:
- Read the target provider/model from the error
- If the target is already in the candidate list, jump directly to that candidate
- If not, insert it at the front and retry immediately
- 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:
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.
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-highspeedfor 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()catchesLiveSessionModelSwitchErrorand records it ascandidate_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
LiveSessionModelSwitchErroris "redirect this request to the session's locked model", not "this candidate has failed".Observed Behavior
186
[ws-stream] WebSocket connect failedwarnings logged in a single day due to repeated fallback attempts.Expected Behavior
When
runWithModelFallback()encounters aLiveSessionModelSwitchError:live_session_redirect, notcandidate_failedThis would reduce the chain from:
to:
Environment
openai-codex/gpt-5.4(ChatGPT OAuth)minimax-cn/MiniMax-M2.7-highspeedNotes