openclaw - 💡(How to fix) Fix Model fallback cascade takes 30s per invalid candidate instead of failing fast (v2026.4.24–.25) [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Split from #75687 (closed prematurely — only Bugs 1–2 were addressed on main). This is Bug 4 from that report.

Non-retryable 400 errors (e.g. invalid model ID, unsupported parameter) take ~30 seconds each before the fallback fires. With a 3-entry fallback chain, a single user message can stall for 90+ seconds before reaching a working model.

In v2026.4.23, the same fallback chain failed over in seconds. The 30s delay in .24/.25 suggests an internal retry or timeout is wrapping deterministic, non-retryable errors.

Example scenario

Chain: groq/model-a (400 invalid) → openrouter/model-b (400 invalid) → anthropic/claude-sonnet

• v2026.4.23: ~2s total to reach claude-sonnet
• v2026.4.24+: ~60-90s total to reach claude-sonnet (30s × 2 invalid candidates)

This is especially painful combined with event loop pressure — the 30s blocking compounds with other CPU-bound work.

Environment

openclaw: v2026.4.24, v2026.4.25 (regressed) — v2026.4.23 (fast failover)
node: 22.21.1
os: Windows 11 Pro N (10.0.26200)
platform: win32
bots: 8 Telegram accounts

Steps to reproduce

1. Configure a model fallback chain where the first 1-2 entries return 400 (e.g. invalid model ID)
2. Send a message to any agent
3. Observe ~30s delay per invalid model before fallback fires
4. Compare with v2026.4.23 where the same chain fails over in seconds

Expected behavior

Non-retryable errors (HTTP 400, 404, invalid model) should fail over to the next candidate immediately — no retry, no timeout. These are deterministic failures.

Actual behavior

Each invalid candidate blocks for ~30 seconds before the fallback fires. A 3-entry chain with 2 invalid models stalls for 60-90 seconds.

OpenClaw version

v2026.4.24, v2026.4.25

Operating system

Windows

Related issues

• Parent: #75687 (closed — only startup fanout and Bonjour crash were fixed)
• Related: #75707 (broader event loop saturation — still open)