Rate Limits

There are no RPM tiers. Your credit balance is the only real limit. If you can afford a request, it runs. A couple of abuse protections sit on top, and you can set optional per-key spending guardrails yourself.

Your balance is the limit

We do not throttle paying traffic into request-per-minute tiers. Send as many requests as your balance supports. The only ceilings are abuse protections, applied per API key:

Anti-flood ceiling

A high universal cap of 1,200 requests/minute per key. It exists purely to stop runaway loops and abuse. Normal, even heavy, usage stays well under it.

Failed-request junk guard

A separate guard throttles floods of failing requests (bad keys, malformed calls). Successful requests never count toward it, so it never gets in the way of real traffic.

Exceeding the anti-flood ceiling returns a 429 with a Retry-After header.

Per-key guardrails

Separately from rate limits, each API key can carry optional spend limits (lifetime, monthly, daily), a model allowlist, an expiry date, and content scanning for prompt injection and sensitive data. These are covered in detail on the Guardrails page.

Rate Limit Headers

Every API response includes rate limit information in the response headers.

X-RateLimit-Limit

The maximum number of requests allowed in the current window.

X-RateLimit-Remaining

The number of requests remaining in the current window.

X-RateLimit-Reset

Unix timestamp when the rate limit window resets.

Retry-After

Seconds to wait before retrying (only present on 429 responses).

Handling Rate Limits

Monitor headers

Check X-RateLimit-Remaining in every response to proactively throttle your requests before hitting the limit.

Exponential backoff

When you receive a 429 response, wait for the duration specified in the Retry-After header. If not present, use exponential backoff starting at 1 second.

Stay under the anti-flood ceiling

For very high-volume applications, spread requests evenly so you stay under the 1,200 requests/minute per-key anti-flood ceiling. A simple client-side queue is enough for almost all workloads.