Skip to main content
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.