Rate limits

Two limits protect the platform and keep latency predictable for everyone: a request rate limit on authenticated calls, and a concurrency limit on generations in progress. Both return 429 rate_limited when exceeded, and nothing is charged for a rejected request.

Default limits#

The request rate is a token bucket: you can send up to 20 requests at once, and capacity refills at 10 per second. Steady traffic below 10 requests per second is never limited.

When you hit a limit#

{
  "error": {
    "code": "rate_limited",
    "message": "Too many generations in progress (limit 20). Wait for some to finish or contact sales for higher limits."
  }
}

• Request rate: wait briefly and retry with exponential backoff and jitter (start around one second). See Retrying safely.
• Concurrency: wait until some of your in-flight generations finish, then submit more. A local queue that keeps at most 20 jobs in flight avoids the error entirely.

Staying under the limits#

Use webhooks instead of tight polling#

Polling dozens of jobs every second burns through the request budget. Pass a webhook_url and let us call you instead — see Webhooks. If you poll, back off to every 5–10 seconds for video.

Queue submissions on your side#

For batch jobs, put work in your own queue and run a fixed pool of workers sized to your concurrency limit. Each worker submits one generation, waits for it to finish, then takes the next.

Share one key per service#

Request rate is counted per key, but concurrency is counted per account. Splitting traffic across more keys does not raise the number of generations you can run at once.