openclaw - 💡(How to fix) Fix [Bug]: OpenRouter Retry-After: 60 causes fallback chain to stall before reaching later providers

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When OpenRouter returns a 429 with Retry-After: 60, the SDK waits the full 60 seconds before falling through to the next provider in the fallback chain.

Steps to reproduce

1. Configure OpenClaw with openrouter/free as primary and paid fallbacks.
2. Hit OpenRouter rate limit causing a 429 with Retry-After: 60 response.
3. Observe fallback chain stalls for 60 seconds before reaching next provider.

Expected behavior

The SDK should respect the configured max wait cap and fall through to the next provider in the fallback chain immediately when the Retry-After delay exceeds the threshold, rather than waiting the full duration.

Actual behavior

The SDK waits the full Retry-After: 60 seconds before falling through to the next provider. Workaround in place: OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=10 in service drop-in config mitigates but does not fix the root cause.

OpenClaw version

2026.4.21

Operating system

WSL2 / Ubuntu 24.04 / Windows 11 Pro

Install method

npm global

Model

openrouter/openrouter/free

Provider / routing chain

openclaw -> openrouter/free -> openrouter paid fallbacks -> deepseek direct

Additional provider/model setup details

Fallback chain: openrouter/free -> openrouter/meta-llama/llama-3.1-8b-instruct -> openrouter/mistralai/ministral-3b-2512 -> openrouter/deepseek/deepseek-v4-flash -> deepseek/deepseek-v4-flash direct. Config lives in ~/.openclaw/openclaw.json under agents.defaults.model. Retry cap set via OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=10 in /root/.config/systemd/user/openclaw-gateway.service.d/retry.conf

Logs, screenshots, and evidence

Impact and severity

Affected: All users with OpenRouter fallback chains Severity: Annoying (delays fallback routing by up to 60 seconds) Frequency: Intermittent - occurs on OpenRouter rate limit hits Consequence: Agent stalls for 60 seconds before reaching next provider, causing slow or failed responses

Additional information

Workaround in place: OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=10 caps the wait but does not fix root cause. SDK should fall through to next provider when Retry-After exceeds the configured max wait threshold.