openclaw - 💡(How to fix) Fix Provider quota/rate-limit errors should trigger model fallback chain, not crash the session [1 participants]

Bug Report

Environment

• OpenClaw version: latest (as of 2026-04-02)
• OS: macOS (Darwin 25.3.0, x64)
• Node: v22.22.0

Description

When a model provider returns a quota/rate-limit error (e.g., Ollama Cloud weekly usage cap at 100%), OpenClaw throws a LiveSessionModelSwitchError and kills the session instead of cascading to the next model in the agent's configured fallback chain.

Agent Config (example)

{
  "primary": "ollama/qwen3.5:cloud",
  "fallbacks": ["openrouter/xiaomi/mimo-v2-pro", "ollama/kimi-k2.5:cloud"]
}

Expected Behavior

When ollama/qwen3.5:cloud returns a quota exceeded error, OpenClaw should:

1. Recognize this as a retryable/fallback-eligible error
2. Automatically try the next model in the fallback chain (openrouter/xiaomi/mimo-v2-pro)
3. Continue the session on the fallback model

Actual Behavior

OpenClaw throws:

LiveSessionModelSwitchError: Live session model switch requested: ollama/qwen3.5:cloud

The session dies. No fallback is attempted.

Impact

This affected 26+ heartbeat cron jobs across all branches simultaneously when the Ollama Cloud weekly quota was hit. Every agent with ollama/qwen3.5:cloud as primary went offline, despite having openrouter/xiaomi/mimo-v2-pro as a perfectly healthy fallback.

The error also occurs on cron-initiated sessions where the cron specifies a different model (e.g., openrouter/xiaomi/mimo-v2-pro) but the agent's configured primary is ollama/qwen3.5:cloud. The session initializes on the cron model, then crashes when the agent tries to switch to its primary.

Additional Context

• The LiveSessionModelSwitchError appears to be a model negotiation issue between cron session model and agent primary model
• Both ollama/qwen3.5:cloud and ollama/kimi-k2.5:cloud share the same Ollama Cloud quota, so both die simultaneously
• Agents on openrouter/* or anthropic/* primaries were unaffected
• These same cron jobs worked fine for hundreds of cycles before the quota was hit

Suggested Fix

• Treat provider quota/rate-limit errors (HTTP 429, quota exceeded responses) as fallback-eligible
• When a model switch fails due to provider unavailability, try the fallback chain before throwing LiveSessionModelSwitchError
• Consider making the cron session model vs agent primary model negotiation more graceful — if the cron model works, don't force a switch to the agent primary