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 a 429 it would only retry a second later. It is served in fair order as capacity frees. 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 the ordinary 429 with retry-after, and the retry recipe applies exactly as before.
  • Nothing about this changes what you send. There is no queue parameter, no ticket to poll, no new status code — the request simply completes.
This is why 429 should be rare on a healthy plan: it now signals your rate limit or a spent allowance (Plans & limits) far more often than it signals our capacity.

​
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.