Limits are set for each account. They keep one customer from using all of the capacity, and they protect your own spending.
Tasks
A provider-run task does not count toward the two running limits. An unfinished task is any task whose status is not final; it is counted when you create a task. A task over a running limit is not an error. It waits, and starts when a task of the account ends. Set namespace on a task to share the running limit fairly between your own users: a user can still queue several tasks.
Requests
Requests are counted for each account, not for each key, in two budgets:
A request over a budget answers 429 rate_limited with Retry-After. The budgets are held approximately, so they can loosen a little under load. The edge also limits each source address.
Headers
Every response to a request made with a key carries:
X-RateLimit-Limit: the budget of the window;X-RateLimit-Remaining: what is left of it;Retry-After: on a429, the whole seconds until you may try again.
Other limits
- A request body is 6 MB at most. A larger one is
413 payload_too_large. idempotencykeys are 128 characters at most; see Idempotency.- An upload is 10 MB at most, and an account holds 100 at a time; see Uploads.
- A linked image is fetched at 10 MB at most and in 20 seconds.
- An account has 50 active keys at most, and 16 registered webhook addresses.
- Each model has its own limits for prompt length, number of images and sizes. They are in the model list.
Video
A video task counts toward limits of its own and toward none of the image limits above. A video that is over a limit is not an error. It waits as PENDING and starts when one of your videos ends.
A video is also one of the unfinished tasks above, so beyond that limit create answers 429 concurrency_limit. The lengths, sizes and first-frame limits of each video model are in the model list and in Video.