Latency
On 15 Sep 2026, SpeechifyAI’s simba-3.2 model returned its first audio byte in 56 ms at the median (p50) and 102 ms at p90 on our production streaming path in US East. That is the part of the wait spent inside our API. What a listener hears also depends on the network between you and US East, how your client connects, the audio format and your player. This page shows how each of those adds up, and how to measure it from where your code runs.
Measured numbers
These are measured percentiles from production traffic, not a guarantee. They are not time to audible audio, and they do not include the network between you and US East.
First byte, first audible audio, total generation time
Generated speech can begin with a short silence, and its length varies with the voice and the text. On POST /v1/audio/speech, time to first byte and total generation time are the same, because the response is sent once the whole clip exists.
How we measure
- What is timed. Every production request to
POST /v1/audio/streamrecords, inside our API, the time from admitting the request (after authentication and rate limits) to writing the first audio byte to the response. - Which requests. Successful streaming requests from real customer traffic, not a synthetic test, split by model. The figures above were read from that traffic on 15 Sep 2026.
- Which statistic. Percentiles, not averages. p50 is the median request; p90 is the request slower than 9 in 10. A few slow outliers move an average, not a median.
- Where. Our US East serving path, which served every request to
api.speechify.aiin September 2026. The clock stops when the first byte leaves our API, so the network between you and US East, the handshakes of a new connection, silence at the start of the audio and your player’s buffer are all outside it. - Cross-checked from outside. We also time requests from the client side: a probe sends varied text to the streaming endpoint from a machine in US East and from other locations, timestamps DNS, TCP, TLS and every chunk, and finds the first audible 10 ms window in the decoded audio. The examples below do the same, without the audio analysis.
What adds latency on your side, and how to cut it
Measure it yourself
Time the first chunk of a streaming response from where your code runs, and read the Server-Timing header on the same response. Its ttfb is our share of that request’s wait, from the request reaching our API to the first audio byte, and model is the model’s own time to first audio. Your first-chunk time minus ttfb is the network and your own stack. ttfb starts slightly earlier than the published figures, so it also counts authentication and rate limiting.
For a fair number:
- Discard the first request or two. They include opening the connection.
- Vary the text between requests, as your real traffic does.
- Send requests one after another. A request beyond your plan’s concurrency limit returns
429, not a slower response. - Take at least 20 requests and report p50 and p90, not the average or the single best run.
- Measure with PCM. With Ogg, the first bytes are header pages, not audio.
Python
TypeScript
cURL
FAQ
Is 56 ms a guarantee?
No. It is the median first byte measured on production streaming traffic on 15 Sep 2026, with p90 at 102 ms, not a service-level commitment. The Server-Timing header on each of your own responses reports the same kind of measurement for that request.
Why do I measure more than 56 ms?
Your measurement includes the network between you and US East, the handshakes of any new connection, and, depending on the tool, decoding and playback. Compare your first-chunk time with ttfb in the Server-Timing header: the difference is everything outside our API.
Which endpoint, model and format give the lowest time to first audio?
POST /v1/audio/stream with model: "simba-3.2" and Accept: audio/pcm, from a client that reuses its connection and runs near US East. simba-3.2 is English only; use simba-3.0 for the other languages it supports.
Does longer text delay the first audio?
On POST /v1/audio/stream, audio starts arriving before the whole input has been synthesized, so send text you already have in one request; total generation time grows with length. On POST /v1/audio/speech, the response waits for the whole clip, so the first audio grows with length.
Where is the API served from?
As of September 2026, every request to api.speechify.ai is served from US East, and the measured numbers on this page are for that path.