Rate limits

429 response

A safe finite delay is returned in the Retry-After header for quota/provider 429 and temporarily unavailable 503 responses when known.

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 18

{
  "error": {
    "code": "routing_exhausted",
    "message": "Provider temporarily unavailable",
    "metadata": {"retry_after_seconds": 18}
  }
}

Limit scope

The applicable limit can vary by workspace, environment, endpoint and agreed capacity. Streaming connections, long-running requests and provider-owned limits may have separate operational effects.

• A Router limit is distinct from an upstream provider limit
• Customer-owned provider accounts remain subject to provider quotas
• A successful fallback still consumes Router capacity
• Ask the workspace owner for the production capacity agreed for the environment

Backoff strategy

Pause for Retry-After when supplied. Otherwise use exponential backoff with jitter. Cap total attempts and concurrency so recovery traffic does not create another limit event.

delay = retry_after_header ?? min(base * 2 ** attempt + jitter, max_delay)

Design for capacity

Use queues or admission control for bursty work, reuse streaming connections carefully, set application deadlines and measure request rate, concurrency and latency separately.