Requests pass through three independent limits. Any one of them can return a 429
(or, at the network edge, a 403). Handle them the same way: back off and retry with
jitter, honoring Retry-After when it is present.
1. Per-IP (network)
A per-IP rate limit at the edge protects the platform from abuse and floods. It is coarse
and applies before authentication. Spreading legitimate traffic across a few connections
and backing off on rejection is enough to stay under it.
2. Per-user fair share
Each account gets a fair share of a model’s serverless capacity, measured in requests
per minute. The share adapts to how many accounts are active on that model, so no single
account can starve the pool. Sustained bursts above your share are throttled with a 429.
If you need a higher guaranteed share, dedicated capacity is available —
contact us.
3. Per-model admission
Each model has an admission controller with a maximum number of concurrent requests
and a bounded queue. When a model is saturated, new requests queue up to the limit and are
then rejected with a 429 (or 503 if there is no healthy capacity at that instant).
This protects latency for in-flight requests rather than accepting work a busy model
cannot serve promptly.
Handling 429s
Exponential backoff with jitter is what keeps a fleet of clients from retrying in
lockstep and re-saturating the model the instant it recovers.