Rate limits

Rate limits are counted per account and per endpoint path: all your keys share one bucket for /v1/chat/completions, another for /v1/messages, and so on. Creating more keys doesn't multiply your quota. A key created with its own per-minute limit uses that limit instead of the account's.

What the limit is

The account limiter counts requests per account and per endpoint path in a sliding 60-second window. The ceiling doesn't come from your plan:

• Every account gets the base per-minute limit (120 requests by default).
• A credit balance at or above a threshold (10 credits by default) raises it (240 by default). The check is cached for five minutes, so a top-up takes effect within that time.
• A key with its own limit uses that limit instead of the account's. Set it when you create the key.
• Concurrency plans add a cap on in-flight requests and a daily request cap on top. See Energy.
• :free requests are throttled by the free tier's own windows, not by this counter.

Defaults can be raised for an account on request — email support.

If you're hitting the per-minute ceiling, move non-critical work to /v1/batches — batch jobs run outside the per-minute request counter. The :batch suffix on a realtime request only changes its routing preference; it doesn't submit an asynchronous job and doesn't lift your rate limit. See Routing.

Reading the headers

Responses carry the current window state, and a 429 carries it too:

Retry-After is the number of seconds to wait, and it can be 0 — treat that as "try again now". A concurrency cap always says 5; a daily cap says the seconds until midnight UTC; the account limiter and provider overloads say the time left in their window. Honor it whenever it's present; when a 429 carries no hint, fall back to your own backoff.

When you're throttled

The account limiter — the per-minute cap this page describes — returns a 429 whose body is flat and has no type: {"code": "RATE_LIMIT_EXCEEDED", "message": "...", "details": {"retry_after": ...}}. Classify it on code, wait the Retry-After seconds, and try again.

Endpoint-level throttles — a plan's concurrency or daily cap — use the endpoint's own envelope instead: type: "rate_limit_exceeded" on /v1/chat/completions and /v1/responses, rate_limit_error on /v1/messages. On a streaming request these caps are reported inside the stream after an HTTP 200, with no Retry-After header — see Errors.

One 429 is not always a throttle. On /v1/chat/completions, a billing refusal also returns 429 — but the body says type: "billing_error". Backing off won't change your balance: read the type before retrying. The same refusal is a 403 on /v1/responses and /v1/messages.

For how to classify each kind of 429 and which to retry, see Errors.

Patterns that work

A few things we've seen from production users:

• Run a small concurrency cap on your end, not the maximum your limit allows. If your limit is 300 requests/minute, running at 250 gives the system room to absorb bursts without 429ing you.
• Split critical and bulk traffic onto separate keys. Same bucket, but scoping lets you cancel the bulk key independently if it runs away.
• For batch-style work, use /v1/batches. It runs outside the per-minute counter, and its lines run under batch routing, which prefers lower-cost providers. There's no per-token discount for being async (Pricing). See Batch workflow.

If you need more

Enterprise plans are negotiated. Email sales if you need a higher ceiling.

Related

Errors beyond 429 (billing, auth, model capability): Errors. Asynchronous bulk work with a separate quota path: Batches.