---
title: "Rate limits and 429 responses"
description: "Handle request rate, concurrency and token limits with bounded retries."
lastUpdated: 2026-10-22
---

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](/en/contact-feedback/contact-feedback) 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.