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

# What you can rely on.

> Layer X1 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 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](/errors) 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](/plans)) 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:

| 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    | Approaching a plan's included usage, the heaviest models pace to your plan while everything else keeps full speed — the `x1-allowance-*` headers count you down the whole way.                                                          |
| Out of usage     | A hard cap, stated plainly: once the month's included usage is spent, requests return `429 allowance_exhausted` with the seconds to reset — 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>