# Rate limits

> The limits per key and per tenant, and the headers that report them.

The read and write API has no published per-key or per-tenant request limit. Published request limits, with headers that report them, are \[Coming].

## The limits that apply today

| What                            | Limit                                                                                        | Refusal                                                 |
| ------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| A request body                  | 256 KiB for most writes; smaller on some (a command 16 KiB, a connector request 4 to 16 KiB) | `422 invalid`: “the body is too large”                  |
| The assistant                   | Its own usage limits, set per tenant                                                         | `429 assistant_capped`                                  |
| A sleeping ephemeral deployment | Reads that need it wait while it wakes                                                       | `503 deployment_waking`, `Retry-After: 5`               |
| Your deployment’s telemetry     | 6,000 records a minute and 2 GiB a day, per deployment and per tenant, by default            | `429 rate_limited`, `Retry-After`, and the limit’s name |

The last is your deployment’s own intake, not your tools’ API calls; the engine’s relay buffers and retries on its own.

## The headers

- `Retry-After`, in seconds, on any refusal where waiting helps. Honour it.
- There are no `X-RateLimit-*` headers.

## Retrying

- Retry only `429`, `502`, `503` and network failures, never another `4xx`.
- Wait for `Retry-After` where it is given; otherwise back off exponentially, starting at one second, with jitter.
- Make writes safe to retry first: see [Idempotency](/api/idempotency/).

## Your models’ rate limits

`GET /api/v1/rate-limits` and **Spend → Rate limits** are different: they show how close each deployment’s busiest minute came to its models’ own limits (requests, input and output tokens a minute) over 24 hours or 7 days, the throttles the providers answered with, and the time calls waited in the gateway’s pacer. See the [Savings and caching reference](/api/reference/savings-and-caching/) and the [`rate_limits`](/mcp/tools/rate-limits/) tool.

Source: https://docs.atlanticagenticlabs.com/api/rate-limits/