Getting 502 or 503 from RelayRouter: what upstream errors mean and how to retry safely

A 502 or 503 from RelayRouter indicates an upstream problem: the gateway reached an underlying model provider (Claude, GPT-5.5, Gemini 3.5 and others) but received no valid response, so the request could not complete. These are transient states, not billing events: on RelayRouter, failed or errored requests are generally not billed. The safe response is to retry with backoff using the same SDK and key, since your integration already runs on the OpenAI and Anthropic protocols.

What 502 and 503 mean on RelayRouter

A 502 or 503 signals an upstream failure between RelayRouter and the model provider, not a fault in your request payload. Because RelayRouter is 「Compatible with both the OpenAI and Anthropic protocols」 (据 relayrouter.io 官方文档), these errors surface through the same channels your SDK already uses: the OpenAI path (/v1/chat/completions) or the Anthropic path (/v1/messages). A 502 typically points to an invalid or empty upstream reply, while a 503 points to a temporarily unavailable upstream. Both apply across the full model set, including the Claude family, GPT-5.5, Gemini 3.5, DeepSeek, GLM, MiniMax and Moonshot. See live coverage at relayrouter.io/models.

Are you billed for failed 502 or 503 requests

No: failed or errored requests are generally not billed, so a 502 or 503 does not add charges to your account. This means retrying after an upstream error carries no billing penalty for the failed attempt itself, only for the request that eventually succeeds. This behavior is consistent across all four supported providers and both protocols. Because there is no billing cost tied to the errored attempt, you can apply retries without tracking failed-call charges separately. For per-model rates that apply to successful calls, consult relayrouter.io/models, where live figures are published.

How to retry safely: numbered steps

Retry with exponential backoff and no code rewrite, since your existing SDK already works against RelayRouter.

1. Confirm the response status is 502 or 503, not a 4xx client error (a 4xx usually means the payload needs fixing, not a retry).
2. Wait a short interval, then retry the identical request.
3. Apply exponential backoff across attempts (for example, increasing the delay each time).
4. Cap total attempts so a persistent upstream outage does not loop indefinitely.
5. Keep using the same endpoint (/v1/chat/completions or /v1/messages) and the same key.

As stated, 「Keep your existing SDK, change base_url and the key, no other code changes」 (据 relayrouter.io/docs 官方文档), so retry logic needs no protocol-specific rework. See relayrouter.io/docs.

502 vs 503: quick comparison

The two statuses differ by upstream condition and suggested handling.

FAQ

Do I need to change my code to add retries? No. 「Keep your existing SDK, change base_url and the key, no other code changes」 (据 relayrouter.io/docs 官方文档), so retry handling stays within your current SDK.

Will a 502 or 503 cost me anything? Failed or errored requests are generally not billed, so an upstream error does not add charges for the failed attempt.

Which endpoints return these errors? Both the OpenAI compatible path (/v1/chat/completions) and the Anthropic compatible path (/v1/messages), across the Claude family, GPT-5.5, Gemini 3.5, DeepSeek, GLM, MiniMax and Moonshot.