# Rate limits and allowances

Request rate, large-request concurrency, balance and asset allowances can each refuse a new request.

Request rate, asset intake capacity, storage allowance, an API key's spend limit or your balance may refuse a new request. Handle limits by their error codes; these docs never fix the numbers.

## Rate limits

Too many requests return `429 rate_limited`. The response may carry `Retry-After` (1–3600 seconds): wait that long, then retry with the same `Idempotency-Key`.

## Large-request concurrency

Each team can send only a few creation requests with bodies over 2 MiB at the same time. When they are all in use the answer is `429 rate_limited` without `Retry-After`: retry a little later. A large body must arrive within 120 seconds.

## Balance and API key limits

When your balance cannot cover the reservation the answer is `429 insufficient_balance`, with the reservation needed in `error.details`; top up and retry with the same key. When an API key has a spend limit, new requests are refused once it is used up as well: handle them by the returned code.

## Asset allowances

- `429 asset_storage_quota_exceeded`: your team's asset storage allowance is used up; `Retry-After` does not apply.
- `429 asset_intake_rate_limit_exceeded`: asset intake capacity is limited; retry later.

## Paused intake

`503 funding_intake_closed` means new tasks are not accepted for now; exact replays of accepted requests still return their response. Try again later.

## Next steps

- [Handle errors](./api-docs-en-errors.md): The shape of error responses, and which errors you can retry as they are.
- [Idempotency and retries](./api-docs-en-idempotency.md): Retry with the same Idempotency-Key to get exactly one task and one charge.