The turn stalls for minutes and then falls back to another model, and the log shows the retry budget being burned one attempt at a time against something that cannot succeed:
transient same-model retry 9/9 for zai/glm-5.3 reason=rate_limit: delayMs=30000
rawError=429 您已达到每周/每月使用上限，您的限额将在 ... 重置
The raw error is a weekly or monthly usage cap with a reset time in it. This is openclaw/openclaw#173436.
Why it happens
Failover classification maps HTTP 429 to rate_limit, and a rate limit is treated as short-lived throttling worth waiting out. Quota exhaustion is long-lived - the cap does not move until its window resets - so every retry in the nine-attempt budget is doomed, and the user waits about four and a half minutes before the fallback that should have happened immediately.
The two look identical at the status-code level. The only reliable tell is the error text, and a per-minute throttle wording has to stay retryable while the weekly or monthly wording does not.
The fix
PR #173485 extends the shared periodic-usage matcher so long-window quota exhaustion skips same-model retries and goes straight to the existing fallback path, while temporary throttles keep their retry budget. It has merged but is not in 2026.10.4 yet.
If you are building failover yourself, the transferable rule is this - classify by whether the failure can clear within the retry window, not by status code. A 429 whose message names a reset time minutes or hours away is a billing-class failure wearing a rate-limit coat. Sending it to the fast fallback path is what the retry budget is supposed to be protecting.