Rate limits
Requests per minute per key, and generations in progress per organization.
Two limits apply:
- Requests per minute, per API key. Every
/v1request counts. New organizations get 600 requests per minute per key. - Generations in progress, per organization. Generations that haven't reached a terminal status count. New organizations can have 20 in progress at once.
Need more? Contact us with your expected volume.
Headers
Every authenticated response says where you stand:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed per minute for this key |
X-RateLimit-Remaining | Requests left in the current window |
X-RateLimit-Reset | Seconds until the window resets |
When you hit a limit
Over the request limit, the API answers 429 with type: "rate_limit", code: "rate_limited" and a
Retry-After header in seconds. Wait that long and try again. The SDKs do this automatically.
Over the in-progress limit, POST /v1/generations answers 429 with code: "concurrency_limit". Nothing
is queued or charged. Retry once one of your running generations finishes. A webhook or the event stream
tells you when that happens. For large batches, keep your own queue and submit as slots free up, rather
than retrying in a loop.
Polling counts against the request limit: polling every two to five seconds per generation is plenty, and webhooks cost nothing.