Rate Limits

Overview

Concurrency limits keep usage fair and the API stable. How many jobs can run at once depends on your plan.

Limits by Plan

Your plan determines your concurrency, which is set per model and counted per user. Higher-tier plans can run more jobs at the same time. Backlogging is also off for Zero Data Retention requests and for some models, including on plans that otherwise allow it. Krea 2 requests are not backlogged on any plan right now.

Job backlog

When backlogging is available, jobs you submit above your concurrency limit are accepted with status: "backlogged". They start, in submit order, as running jobs finish. There is no separate backlog cap. When backlogging is not available, a further job can be rejected with HTTP 429 instead of being queued. The cap is approximate: a short burst can still be accepted above it. On 429, retry with backoff after in-flight jobs finish. The body and headers are in Errors and debugging.

Best Practices

• Implement exponential backoff - Wait progressively longer between retries
• Queue requests client-side - A burst can be accepted above the cap, so don’t rely on the API to stop the next request
• Monitor your usage - Track request counts to stay within limits
• Use webhooks - Reduce polling requests by using webhooks for job completion

Next Steps