Summary

OpenClaw falsely puts both configured providers (anthropic/claude-opus-4-6 and openai-codex/gpt-5.3-codex) into cooldown simultaneously, even when no actual API rate limit has been hit. The cooldown reason is hardcoded as "rate_limit" regardless of the actual failure (see #5240). Downgrading to 2026.2.12 immediately resolves the issue without any config changes. The Anthropic token uses sk-ant-oat01- prefix (OAuth Access Token from Claude Max), which may be relevant if cooldown logic handles OAuth tokens differently.

Steps to reproduce

1. Configure OpenClaw 2026.2.21-2 with anthropic/claude-opus-4-6 as primary and openai-codex/gpt-5.3-codex as fallback
2. Use Anthropic OAuth token (sk-ant-oat01- prefix) stored as type "token" in auth-profiles.json
3. Use Telegram as input channel
4. Send messages normally — after some usage, both providers enter "cooldown" simultaneously
5. No actual API rate limits are being hit on either provider

Expected behavior

Provider cooldown should only activate when the API actually returns a 429/rate-limit response. The cooldown reason should reflect the actual failure (timeout, auth error, billing, etc.) instead of being hardcoded as "rate_limit" (see #5240). Both providers should not enter cooldown simultaneously unless both APIs are genuinely rate-limited.

Actual behavior

Both providers enter cooldown simultaneously with error: "All models failed (2): anthropic/claude-opus-4-6: Provider anthropic is in cooldown (all profiles unavailable) (rate_limit) | openai-codex/gpt-5.3-codex: Provider openai-codex is in cooldown (all profiles unavailable) (rate_limit)." Agent fails to reply entirely. No recovery without gateway restart or version downgrade.

OpenClaw version

2026.2.21-2 (35a57bc)

Operating system

Windows 11 (Hyper-V VM)

Install method

npm global

Logs, screenshots, and evidence

Screenshots posted under "Additional Information".

Impact and severity

Affected: All channels (Telegram, Discord, Gateway)
Severity: Critical (completely blocks all agent replies with no automatic recovery)
Frequency: Reproducible — occurs on every upgrade to 2026.2.21-2, resolves on every downgrade to 2026.2.12
Consequence: Agent becomes fully unresponsive. Owner must manually restart or downgrade to restore functionality.

Additional information

Related: #5240 — Provider cooldown reason is HARDCODED as "rate_limit" regardless of actual failure (timeout, billing, auth error, etc.). This appears to be the root cause.

Also related: #13909 (OAuth 403 misclassified as rate_limit), #8226 (same error message, user stuck), #8520 (cron retry loops triggering cooldown), #13336 (local Ollama falsely entering cooldown after timeout).

Testing performed:

1. On 2026.2.21-2: Both anthropic/claude-opus-4-6 and openai-codex/gpt-5.3-codex falsely flagged as rate limited simultaneously
2. Downgraded to 2026.2.12: Both providers work perfectly — no config changes made
3. Upgraded back to 2026.2.21-2: False rate limits returned immediately
4. Removed Rabbit R1 device entirely and retested on 2026.2.21-2: False rate limits STILL occurred — confirmed not caused by external device
5. Manually switched to GPT-5.3 Codex on 2026.2.12: Works fine, proving the "API limit reached" error for Codex was also a false positive

The Anthropic token uses sk-ant-oat01- prefix (OAuth Access Token from Claude Max subscription), stored as type "token" in auth-profiles.json. This may be relevant if the cooldown logic handles OAuth tokens differently than standard API keys.

Auth format must be: { "type": "token", "provider": "anthropic", "token": "" } — using "type": "api_key" with "key" field does NOT work for OAuth tokens and may contribute to misclassified errors.

No rate limit or cooldown settings exist in user config (openclaw.json) — this is entirely internal OpenClaw behavior.