capability
verified July 2026
Serving that degrades before it fails.
A live call cannot buffer, retry quietly, or show a spinner. So the serving stack is built on one rule: overflow costs the caller latency, never availability — and when even that runs out, the refusal is fast and machine-readable.
01
The three tiers
Fig. — One endpoint, three strata
01Primary GPU fleet
takes all traffic first
the published figures: 107 ms first audio single-stream
02Warm spill
model loaded, idling until the fleet fills
overflow costs latency, not availability
03Independent fallback
a separate failure domain, always answering
the farthest tier — still audio, never silence
past absolute capacity: 503 at_capacity, retryable — never dead air on a live call
02
The refusal, in full
Past what all three tiers can serve, the API refuses fast instead of letting every stream degrade — a full lane never quietly slows the others. The refusal is a signal your orchestrator can act on:
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 a standby line, reschedule the job.
# the one thing that never happens: dead air on a live call
03
How to hold us to it
The load benchmark publishes what one GPU does at sixteen callers — 430 ms median, 813 ms p95, zero failed requests — because a reliability claim without a load figure is a slogan. For your own posture, standby failover lines run the same discipline in the other direction: our capacity idling beside your current vendor at $20 a month.
04
Notes — an engineer's checklist
01What does a fleet outage look like from my side?
Latency, not errors: traffic lands on the warm spill tier, which is already loaded and answering health checks, and past it on the independent fallback. The request still returns audio, from a warmer or farther tier.
02Why 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.
03Is the 503 counted against my lines?
No — a refused request is not a conversation. If refusals correlate with your own traffic spikes, that is the signal to raise the burst cap or add a committed line.
04Can I make my stack resilient to you?
Yes, and we sell the tool: standby failover lines hold tested capacity beside any primary vendor — including treating us as the primary — at $20 a month per line.
See also
Related sheets.
benchmark
813 ms
How the API behaves under load
What one GPU does under 16 concurrent callers — 430 ms median, 813 ms p95, zero failed requests — and how the API refuses traffic past absolute capacity.
glossary
loaded
Warm spill
Warm spill is a second serving tier that is already running when the primary fleet fills, so overflow traffic costs latency instead of availability.
capability
$20
Standby lines for the vendor’s bad night
Standby failover lines run beside your current TTS provider for $20 a month each and activate automatically when it goes dark. Capacity insurance, priced.
capability
$10
Burst lines: capacity priced by the day
Traffic past your committed lines spills to burst lines at $10 a line-day, capped in your dashboard — capacity for spike days without paying for them all year.
Your script, this API, thirty minutes — and the recording leaves with you.
Hear it on your own script