Rate limits

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.

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 and the rate_limits tool.