Limits can apply by customer, API key, model or model type. Read the response headers for the limit that affected your request. Requests exceeding an active limit receive 429 Too Many Requests; temporary upstream capacity limits can also produce 429.

​
What is limited

  • RPM: requests per minute; burst limits control short spikes.
  • Concurrency: synchronous, streaming or realtime requests still running.
  • Input and output TPM: tokens processed per minute.
  • Active asynchronous tasks: image or video tasks that have not reached a terminal state.
Polling task status and retrieving results do not consume generation-request allowance again, but ordinary API abuse limits still apply.

​
Response headers

Retry-After gives the suggested wait in seconds. Headers may include x-ratelimit-limit-requests, x-ratelimit-remaining-requests and x-ratelimit-reset-requests. Concurrency and token limits use corresponding concurrent-requests, input-tokens or output-tokens suffixes.

​
Respond safely

  1. Honor Retry-After; do not retry in a tight loop.
  2. If absent, use bounded exponential backoff with jitter, such as increasing waits of 1, 2, 4 and 8 seconds.
  3. Close completed streams and limit the worker count for batch jobs.
  4. Do not assume that creating more keys increases a shared customer allowance.
If individual requests keep failing, contact support with the time, model ID, error and Request ID. For higher throughput, provide target models, peak RPM/TPM, concurrency and calling hours. Only an agreed and active policy defines the resulting limit.