> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sideren.io/llms.txt
> Use this file to discover all available pages before exploring further.

# What you can rely on.

> Sideren is built to be the boring part of your stack. This page is the contract: the behaviors you can design an agent around, stated as outcomes — not implementation.

## 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](/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](/errors) 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](/plans)); 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:

| Behavior | Contract |
| - | - |
| Published limits | Requests/min and concurrency per plan, printed on [Plans & limits](/plans) — no unpublished throttles to discover in production. |
| Self-pacing | Every response carries `x-ratelimit-*` headers so clients can slow down before hitting the limit. |
| On the limit | `429` with `retry-after` in seconds — never a hang, never a dropped connection. |
| Near the edge | The `x-sideren-monthly-used-percent` header and the dashboard show how much of the month you have used, and the dashboard warns you as you get close. |
| Out of usage | A hard limit, stated plainly: once the month's credits are used, requests return `402 allowance_exhausted` with the date they renew. Never a silent partial answer, never a bill past your plan. Upgrading lifts it immediately. |

<Note>
  Everything on this page is observable from the outside — statuses, headers, and stream
  events. If a behavior isn't stated here or on [Errors](/errors) / [Headers](/headers),
  don't build against it.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.