Serving that degrades before it fails.
3 tiers
behind one endpoint
One serving stack renders every workload, from an audiobook to a live call, under a single rule: overflow costs you latency, never availability. When even that runs out, the refusal is fast and machine-readable.
The three tiers
What that looks like
Most of the time you never see the tiers move: the primary takes a live call, an audiobook render and a dubbing pass alike, at the published figures. When the fleet fills, the next request lands on warm spill.
The refusal, in full
Past what all three tiers can serve, the API refuses fast instead of letting every stream degrade. Your orchestrator gets a signal it can act on:
listing 01
what past-capacity actually returns
HTTP/1.1 503 Service Unavailable
retry-after: 1
{"error": "at_capacity", "retryable": true}
# a busy signal your orchestrator can act on ,
# retry, spill to failover, reschedule the job.
# the one thing that never happens: a pipeline stalled in silence
How to hold us to it
Every figure we publish states the conditions it was measured under. The pair on this site is single-stream, server time to first audio. Run your own script and read the ttfa_ms on every utterance.
Notes
What does a fleet outage look like from my side?
Latency, not errors. Serving is redundant, so the request still returns audio. It may take longer to arrive.
Why refuse instead of queueing?
Because a queued live call is dead air, the one failure a caller cannot interpret. A fast retryable 503 gives your orchestrator something to act on inside the same second.
A key, one stream, your own script, nothing on it counted while you build.
Get a key, run your own script