Skip to main content

Always on

Zero downtime is the design target, not a status-page apology. Serving is watched and rebalanced continuously, and capacity is provisioned so that your traffic never depends on any single model deployment being healthy.
  • No scheduled maintenance windows — the API does not go down on purpose.
  • Model launches, catalog updates, and platform releases are invisible in-band: no API version bumps that break a running agent.

Sessions keep moving

Agent runs are long and stateful, so the guarantee that matters is continuity: if a model can’t answer, the engine keeps your session moving. You don’t write failover lists, health checks, or fallback logic — a request that can be served, will be. When a response genuinely cannot be produced, you get a clean, protocol-shaped 5xx that says so (The model did not return a response. Please retry.) — transient by design, built to be retried. See Errors for the recipe.

Saturation queues before it sheds

When every model that could serve a request is at capacity, the request takes a place in line rather than being handed an error it would only retry a second later. It is served in order as capacity frees, with paid plans first. What that means for your client:
  • A request under saturation shows up as latency, not an error. Set client timeouts with headroom — a hard 5-second deadline turns a request that would have been served into a failure of your own making.
  • The wait is bounded. Past the ceiling you get a 503 (529 overloaded_error on /v1/messages) with retry-after, and the retry recipe applies.
  • Nothing about this changes what you send. There is no queue parameter, no ticket to poll, no new status code — the request simply completes.
So a 429 signals your plan’s rate limit and a 402 your plan’s credits (Plans & limits); our own capacity shows up as a wait, and only rarely as a 503.

Honest streams

A stream either completes or tells you it didn’t. If a streamed turn cannot finish, it ends with a protocol-shaped error event — you will never receive a silent empty 200 that your agent mistakes for “the model had nothing to say.”

Predictable limits

Rate limiting is boring on purpose — published numbers, standard signals, machine-readable timing:
Everything on this page is observable from the outside — statuses, headers, and stream events. If a behavior isn’t stated here or on Errors / Headers, don’t build against it.