Back to changelog

Concurrent Request Limits and Overload Protection

Every organization now has a fleet-wide budget of concurrent in-flight requests that scales with your trust tier — bounding the long-running streams a per-minute limit can't see. Over-budget requests get a retryable 429, and a momentarily saturated gateway sheds load with a 529 instead of queueing until it degrades.

Concurrent request limits: a circuit board with parallel request lanes flowing into a central gateway chip, some lanes held back by a glowing gate

A per-minute rate limit can't see duration. Six hundred requests per minute sounds bounded — until each one streams for two minutes and holds 1,200 connections open at once. Long-lived agentic streams pile up in a way RPM budgets never notice, and one tenant's runaway parallelism can exhaust shared gateway capacity for everyone else. Concurrent request limits close that gap: each organization now has one fleet-wide budget of in-flight requests across all inference endpoints — chat completions, messages, responses, embeddings, moderations, rerank, OCR, images, speech, transcriptions, videos, and the AI SDK surface.

How Slots Work

A slot is held for a request's full lifetime — including the entire duration of a streamed response — and freed the moment the response finishes or the connection closes. Slots free up continuously as requests complete, so there is no fixed window to wait out: a retry after a short backoff typically succeeds.

For pay-as-you-go organizations the ceiling scales with the same trust tier that already drives your per-minute limits and spend caps:

Plan Concurrent requests
Regular (PAYG) — Tier 0 100
Regular (PAYG) — Tier 1 200
Regular (PAYG) — Tier 2 400
Regular (PAYG) — Tier 3 1,000
Regular (PAYG) — Tier 4 2,000
Dev plan 50
Chat plan 10
Enterprise 2,000

Requests over the budget are rejected with a retryable 429:

1HTTP/1.1 429 Too Many Requests2Retry-After: 13
4{5    "error": {6        "message": "Too many concurrent requests for this organization (limit: 100). Retry shortly, or reduce request concurrency.",7        "type": "rate_limit_error",8        "code": "rate_limit_exceeded"9    }10}

Unlike the per-minute limits, Enterprise organizations are not exempt — unbounded single-tenant concurrency exhausts shared capacity regardless of plan. They get the top-of-ladder ceiling instead, and can contact us to raise it further.

Overload Shedding (529)

The same release adds pod-level backpressure. When a gateway instance is momentarily at its own capacity, new inference requests are shed instantly with a 529 and Retry-After: 1 — matching Anthropic's 529 Overloaded — instead of queueing until the instance degrades. Health checks and /v1/models are never shed, so the rest of the fleet keeps absorbing traffic while the hot instance recovers.

429 529
Cause Your organization exceeded its concurrency limit The gateway is momentarily at capacity
Fix Reduce client-side parallelism, then retry Retry immediately with backoff
Retryable As soon as one of your in-flight requests ends Yes, within seconds

Both responses carry Retry-After — respect it with exponential backoff and a spike passes through instead of failing.


Rate limits docs → | Contact us about Enterprise →