429 Too Many Requests: a practical backoff guide

Separate client-side burst, relay group limits, and upstream overload, with a retry pattern.

Reviewed 2026-11-12 · Chinese detail: 完整中文页

429 is a rate limit, not a bad key

On a direct provider endpoint, 429 usually means you are sending requests faster than your tier allows. On a relay, it often means the concurrency limit of your group is full, which has nothing to do with your code.

The 60-second test

Wait 60 seconds and send the same request once. If it succeeds, you were rate-limited. If it still fails, check the relay status page and try a different group or model.

Retry correctly

Use exponential backoff with jitter, cap the number of attempts, and retry only on 429 and 5xx responses. Do not retry 400 or 401. For streaming requests, make sure a retry does not duplicate a charge.

Reduce concurrency before increasing the timeout. A queue with a fixed worker count is easier to reason about than an unbounded pool.

When it is the relay

If the same request succeeds on another group but fails on yours, the group is saturated. Ask support for the group's concurrency limit and whether a dedicated group is available. Do not assume the relay is down.

When it is upstream

If several unrelated relays and the official endpoint all return 429 for the same model, the upstream provider is overloaded. Route to a different model or wait; retrying harder will not help.

This page is general guidance, not a statement about any specific provider. For measured data, see the relay directory and method.