Retry Policy for Outbound Provider Calls

Goals

• Retries happen for each HTTP request, not for an entire multi-step workflow.
• Order is kept intact because only the step currently being executed is retried.
• Non-idempotent actions are not repeated.

Defaults

Behavior

Model providers

• Short retries are normally delegated to the provider SDKs by OpenClaw.
• With Stainless-based SDKs, including those from Anthropic and OpenAI, retryable responses (408, 409, 429, and 5xx) may carry retry-after-ms or retry-after. If that wait exceeds 60 seconds, OpenClaw inserts x-should-retry: false so the SDK reports the error right away, and model failover can switch to a different auth profile or a fallback model.
• The cap can be changed using OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=<seconds>. Assign it 0, false, off, none, or disabled so SDKs can respect long Retry-After sleep periods internally.

Discord

• Rate-limit errors (HTTP 429), request timeouts, HTTP 5xx responses, and transient transport issues like DNS lookup failures, connection resets, socket closes, and fetch failures all trigger retries.
• Discord's retry_after is used when it exists; otherwise, exponential backoff applies.

Telegram

• Transient errors (429, timeout, connect/reset/closed, temporarily unavailable) are retried.
• retry_after is used when available, falling back to exponential backoff otherwise.
• HTML/Markdown parse errors skip retries and revert to plain text on the initial attempt.

Configuration

Timing for retries on Discord and Telegram channels is hardcoded and cannot be adjusted through openclaw.json.

Notes

• Each request (message send, media upload, reaction, poll, sticker) is retried individually.
• Steps already completed in composite flows are not retried.

Related

• Model failover
• Command queue