ElevenLabs publishes ~75ms for Flash v2.5, Deepgram 80ms for Flux TTS, Cartesia sub-90ms for Sonic, and Rime 37ms TTFA for Mist v3. We opened all four vendor pages on 10 September 2026 and traced every figure. None of them measures the same thing, and none of them is the number your callers will hear.
Every “fastest text to speech for voice agents” listicle prints those four numbers in one column as though a lab measured them side by side. Nobody did. Each figure is a marketing number produced under conditions its own vendor chose, and in two cases the vendor tells you exactly what it left out — if you read the footnote. This page is the footnote.
It stays on the text-to-speech layer deliberately. For how much latency budget a turn has in total, and where the other three stages spend it, see our companion post on why sub-second responses matter in voice AI.
The four things that decide a TTS choice, before you look at a single number
Criteria first, because the comparison is meaningless without them. A published latency figure is only comparable to another published latency figure when both sit in the same four columns. We call this the Four-Column Rule, and it is the whole reason the numbers in the next section cannot simply be ranked.
Two TTS latency numbers are comparable only when metric, transport, concurrency and network position all match. Change any one of the four and you are comparing different quantities that happen to share a unit.
| Column | What to ask the vendor | Why it moves the number |
|---|---|---|
| 1. Metric | Is this time to first audio byte, or total time to synthesise the whole reply? | Deepgram documents both for the same request: 616ms time to first byte inside a 745ms total, on one example call to aura-2-thalia-en. |
| 2. Transport | Streaming WebSocket, or a batch REST request? | Deepgram’s own docs give a non-streaming total-latency model for Aura-2 that starts at roughly 600ms. Its 80ms headline belongs to a different product, Flux TTS, and that page does not state a transport at all. |
| 3. Concurrency | At how many simultaneous streams, and at which percentile? | Rime is the only one of the four publishing this. Coda goes from 96ms P50 at 1 concurrent stream to 150ms P50 at 12. |
| 4. Network position | Measured from where, to which region? | Deepgram states its servers are exclusively in the United States. Rime puts continental-US round-trip at typically 25 to 50ms on top of the model figure — but only when you pick the closest regional endpoint. Its own table puts East Coast traffic to US West at 60 to 85ms. |
Nothing in that table is a criticism of any vendor. Three of the four columns are disclosed somewhere in the vendor’s own documentation. They are simply not disclosed on the page the listicles copy from.
Which TTS publishes the lowest latency, and what each figure excludes
This is the table the page exists for. The differentiating column is the third one: what each published number leaves out, in the vendor’s own words. The fourth column records who owns each figure and where it is published. Date checked: 10 September 2026 for every row, on the owner’s own site — no summariser, no comparison blog.
| Model | Published figure, verbatim | What the vendor says it excludes or measures | Owner (organisation) and source page |
|---|---|---|---|
| ElevenLabs Flash v2.5 | “Ultra-low latency (~75ms†)” | The dagger is the asset. Its footnote on the same page reads: “† Excluding application & network latency”. 32 languages, 40,000 character limit. | ElevenLabs elevenlabs.io/docs/models |
| ElevenLabs v3 Conversational | “Low latency (~280ms)” | Same dagger footnote, same table. 70+ languages. | ElevenLabs elevenlabs.io/docs/models |
| ElevenLabs Multilingual v2 and v3 | No latency figure in that table | Those cards carry language counts, character limits and quality descriptions, but no millisecond figure. The page separately notes Multilingual v2 has “a higher latency & cost per character than Flash models”. | ElevenLabs elevenlabs.io/docs/models |
| Cartesia Sonic 3.5 | “sub-90ms latency” | Stated in the model’s opening sentence with no metric, transport, concurrency or network position given. Sonic 3.5 is now listed under Older Models; the docs recommend Sonic 3.6. | Cartesia docs.cartesia.ai/build-with-cartesia/tts-models/sonic-3-5 |
| Cartesia Sonic 3.6 (current GA) | “sub-90ms latency” — on the marketing page only | The docs page calls it “our fastest, most natural text-to-speech model, with native support for 44 languages” and carries no millisecond figure; neither does cartesia.ai/pricing. Cartesia’s product page does publish one for the current model: “Ranked #1 for naturalness, sub-90ms latency, and natively multilingual across 44 languages”, with no metric, transport, concurrency or network position given. All three pages read 10 September 2026. | Cartesia docs.cartesia.ai/build-with-cartesia/tts-models/latest cartesia.ai/sonic |
| Deepgram Flux TTS | “Output that starts in as low as 80ms, even under production load.” | Start of output, so a first-byte metric. Transport, concurrency and measurement location are not stated on that page. This figure sits on the Flux TTS product page, not on Aura or Aura-2. | Deepgram deepgram.com/product/text-to-speech |
| Deepgram Aura-2 | No headline millisecond figure; a published latency model instead | The docs give “total_latency = constant_latency + latency_per_100_characters * num_characters”, with the constant “relatively constant at ~600 ms for total latency without streaming” and the slope “~40 ms per 100 characters”. Non-streaming, total, US-hosted. | Deepgram developers.deepgram.com/docs/text-to-speech-latency |
| Rime Mist v3 | 37ms TTFA P50 at 1 concurrency; 37ms P50 / 56ms P90 at 12 concurrency | The most fully disclosed figure of the four. Rime names the machine: “a single Lambda H100 SXM machine with an H100 SXM5 GPU, 26 vCPUs, 221 GiB RAM, Ubuntu 24.04”. Excludes network round-trip, which Rime separately puts at “typically 25–50ms from most of the continental US when you pick the closest regional endpoint” — that last clause matters, because Rime’s own table puts East Coast to US West at 60–85ms. | Rime docs.rime.ai/docs/latency |
| Rime Coda | 96ms TTFA P50 at 1 concurrency; 150ms P50 / 181ms P90 at 12 concurrency | Same machine, same table. Rime’s “sub-100ms model latency” claim for Coda is scoped in its own sentence to “the GPU engine when self-hosted or on-prem”. | Rime docs.rime.ai/docs/latency |
Two numbers that circulate widely did not survive the trace, and we are not repeating them. There is no 40ms Cartesia Sonic figure on the Cartesia pages we read on 10 September 2026 — the docs (including the full llms-full.txt index of docs.cartesia.ai), cartesia.ai/sonic and cartesia.ai/pricing — and Deepgram’s 80ms belongs to Flux TTS, not to Aura-2 — developers.deepgram.com/docs/tts-models, read the same day, publishes no millisecond figure for either Aura generation. This is exactly the pattern we set out in why vendor documentation outranks a vendor marketing page as evidence: the docs are slower, drier and correct.
How long does a real agent reply actually take? A worked example from Deepgram’s own docs
Deepgram is the only vendor of the four that publishes enough to let you compute a prediction, so we use its numbers. Its documented model for non-streaming Aura-2 requests is:
total_latency = ~600 ms + (~40 ms × number of characters / 100)
A typical outbound agent turn — a confirmation plus a question, say “Great, I have you down for Thursday at 2pm. Would you like the reminder by SMS or email?” — is about 90 characters. Run it through:
- 90-character reply: 600 + (40 × 0.9) = 636 ms
- 220-character reply (a short qualification answer): 600 + (40 × 2.2) = 688 ms
- Deepgram’s own 300-character example: predicted 600 + (40 × 3) = 720 ms; the measured run in its docs came back at 756 ms
- Deepgram’s own 900-character example: predicted 960 ms; measured 879 ms
Deepgram attaches its own caveat, and it should be quoted rather than paraphrased: “You will notice variation in latency; these numbers are an illustration of general trends and concepts, not a fixed result.” It also documents the fix, which is to stream: play audio from the first byte rather than waiting for the file, because “Streaming of results begins once the first byte of audio is synthesized.”
The gap between 80ms and 688ms is not a vendor exaggerating; it is a first-byte figure for one product read against a total non-streaming figure for a different one, as though the two were the same measurement. That is the Four-Column Rule failing in a single row.
Why my dashboard shows 50ms and my caller still hears a pause
This is the documented-failure section, and it is worth more than any of the published figures because every item in it is dated, public and reproducible. The number your telemetry reports is a property of your client library and its configuration, not of the TTS vendor.
Two dated, public examples from the Pipecat framework’s issue tracker — the orchestration layer a large share of production voice agents run on:
- Stale first-turn TTFB. pipecat-ai/pipecat issue 3451, opened 14 January 2026 and closed the next day, reported that WebSocket TTS services “only call
start_ttfb_metrics()on the first TTS request of a conversation. Subsequent requests reuse the existingcontext_idand skip TTFB measurement entirely.” The issue lists eight affected services, including the Cartesia, ElevenLabs and Rime integrations, and gives the consequence as “Telemetry dashboards show incorrect TTFB percentiles.” The maintainer disputed that reading the same day, and the issue was closed with an explanation rather than a code change: “The way it’s designed, you get a TTFB value for the first bot output for each turn. This is as good as Pipecat can do and is the most important measurement to make.” He added that “once the stream of audio is returned from the TTS provider, there’s no way to tell which TTS generation corresponds to which audio chunk, so further precision is non-trivial and would require changes by the TTS providers”. Read either way, the operational fact is the same: the TTFB your framework reports is not a per-request measurement of the model. - The transport, not the model. pipecat-ai/pipecat issue 3110, opened 21 November 2025 and closed five days later, recorded that the Deepgram TTS service “currently uses REST API (
asyncrest.stream_raw()) despite the misleading name, resulting in ~3s STT-TTS latency”, where the WebSocket endpoint “could achieve <1s latency”. Read the units carefully: the ~3s is the reporter’s speech-to-speech figure for the whole loop, not a TTS-only measurement, and the <1s was a projection rather than a result. The fix was real, though — pull request 3115, merged 26 November 2025, moved the service onto Deepgram’s WebSocket TTS API. Same model, same vendor; the variable was the transport the client library opened.
Both issues are closed, and they closed differently: 3110 by a merged code change in five days, 3451 by the maintainer explaining that the behaviour is intended. Neither of them turned on the TTS model. That is the point — before you attribute milliseconds to a vendor, establish what your own client library measures and which transport it opened.
There is a third trap, and Cartesia documents it against itself on its own buffering page, read 10 September 2026: the max_buffer_delay_ms parameter has a range of 0 to 5000ms and a default of 3000ms. Cartesia’s warning is explicit: “A common mistake is to aggregate text client-side into sentences or phrases and use the default max_buffer_delay_ms of 3000ms. This can cause unnecessary latency—after receiving a complete sentence, the API may wait up to 3000ms for additional input before generating speech.” A sub-90ms model can sit behind a three-second wait that nobody configured, because it is the default. Publishing that warning is good documentation; the failure is ours if we do not read it.
ElevenLabs documents a fourth, on the same page as its 75ms figure: once you exceed your plan’s concurrency limit, “subsequent requests are processed in a queue alongside lower-priority requests. In practice this typically only adds ~50ms of latency.” A disclosed 50ms is not a problem. An undisclosed one would be.
How to measure TTS latency on my own stack in 20 minutes
Vendor figures are a shortlist tool, not an answer. This is the second thing worth taking from this page: a method that produces a number for your stack, adapted from the measurement procedure Deepgram publishes in its own latency documentation.
- Measure your network position first, before any model. Run
curl -sSf -w "connect: %{time_connect}\n" -so /dev/null https://<vendor-api-host>from the machine your media server actually runs on — not your laptop. Anything you find here is a floor under every figure that follows. If you are calling Australian numbers against a US-hosted API, this is where the budget goes. - Split the request, do not time the whole thing. Capture
time_namelookup,time_connect,time_appconnectandtime_starttransferseparately. Deepgram’s documented example shows why: a 616ms time to first byte is 277ms of model once you subtract the 339ms TLS handshake. - Use your real turn length. “Hello world” is not a sales call. Character count moves the number roughly linearly, at about 40ms per 100 characters on the one model where a vendor publishes the slope.
- Use your real concurrency. Run the test at the number of simultaneous calls you actually expect at 10am on a Tuesday, not at one. Rime’s published table is the warning: Coda’s P50 rises from 96ms to 150ms between 1 and 12 concurrent streams.
- Report P90, not the mean, and never turn one. Take the measurement from turn five onward. Issue 3451 above is the whole argument about what a framework-reported TTFB actually covers; measuring outside the framework settles it for your stack.
- Re-run it after every dependency bump. A client-library change moved a Pipecat integration from three seconds to under one without any model changing.
A latency figure without a stated metric, transport, concurrency and measurement location is not a benchmark; it is a brochure line. Run the six steps and you will have the only figure that binds anyone.
Running that method honestly costs something, and it is worth saying plainly: it is roughly half a day to build the harness, a paid account on each vendor you shortlist, a load generator that can hold your real concurrency, and a repeat run every time a dependency moves. Most teams do it once, learn that network position dominates, and never repeat it. That is a defensible choice as long as you know you made it.
Who each option is wrong for
Every row here comes from the vendor’s own documentation. An unpublished figure is a documentation gap, not a defect, and we have written it that way.
| Option | Wrong for | The documented reason |
|---|---|---|
| ElevenLabs Flash v2.5 | Agents that read back account numbers, dates or currency amounts without normalising them upstream, on a non-Enterprise plan | ElevenLabs states that “By default, normalization is disabled for Flash v2.5 to maintain the low latency”, that phone numbers “might be read out in way that isn’t clear for the user”, and that the apply_text_normalization parameter is Enterprise-only for v2.5 models. Its own advice is to normalise in the LLM first. |
| Cartesia Sonic 3.6 | A procurement process that requires a documented, method-disclosed latency figure for the exact model you will deploy | The only sub-90ms figure in the documentation belongs to Sonic 3.5, which the docs now list under Older Models. Sonic 3.6 does carry a sub-90ms claim on Cartesia’s marketing page, but not on its documentation page or its pricing page, and the marketing claim states no metric, transport or concurrency. All three pages read 10 September 2026. |
| Deepgram Aura-2 via the cloud API | Australian or European call traffic where round-trip time is already the largest line in the budget | Deepgram’s docs state plainly: “Deepgram’s servers are exclusively in the United States. If you are making API requests from another country, this will incur relatively higher network latency than requests from the USA.” It documents self-hosting as the remedy. |
| Deepgram Flux TTS | A budget locked in before mid-September 2026 | The pricing page read on 10 September 2026 shows Flux TTS as “Free until 9/12 Then $0.0450/1k characters”, with the product page adding that “Standard pricing applies beginning September 13, 2026.” Aura-2 is listed at $0.030/1k characters and Aura-1 at $0.0150/1k characters on the same page. Re-read it before you sign anything. |
| Rime Coda | Cloud-only deployments expecting the headline sub-100ms number | Rime scopes it honestly itself: sub-100ms model latency is stated for the GPU engine when self-hosted or on-prem, and the cloud figure is given separately as sub-200ms end-to-end under typical conditions. |
| Any of them, chosen on published numbers alone | Anyone who has not yet measured their own network position | The spread between the fastest and slowest published model figures here is about 250ms. A single badly placed media server, or one 3000ms buffering default, is larger than the entire spread. |
Where the TTS number sits in the rest of the turn
Text-to-speech is one of four stages, and on most real calls it is not the largest. Endpointing, model time-to-first-token and telephony transport all take their share, and a mid-call CRM or knowledge-base lookup can dwarf all of them — which is why we treat retrieval latency during mid-call knowledge lookups as a separate budget line rather than rounding it into the LLM. The full stage-by-stage breakdown, with the human turn-taking research behind the targets, is in our post on voice AI latency and sub-second responses.
Two structural levers move more milliseconds than any model swap. The first is where the inference runs relative to the caller: Deepgram’s US-only server note above is the clearest published example of why. The second is whether you can move the model onto infrastructure you control at all. Zian AI runs live phone, SMS, email and WhatsApp outreach across 30+ languages, and supports private model deployment on customer infrastructure — which exists for exactly this class of problem, where network position rather than model choice is the binding constraint. More questions of this shape are collected on our AI sales agent FAQ hub.
Zian is currently in partnership-application beta. There is no free trial and no self-serve signup — the way in is to Apply For Partnership, which is also why we can publish a comparison page that recommends measuring before you buy anything.
Frequently asked questions
Which TTS has the lowest published latency for voice agents?
On the vendor pages we read on 10 September 2026, Rime Mist v3 publishes the lowest figure at 37ms TTFA P50, followed by ElevenLabs Flash v2.5 at roughly 75ms, Deepgram Flux TTS at 80ms and Cartesia Sonic 3.5 at sub-90ms. Those four figures are not measured the same way, so ranking them is not a valid comparison.
Is 75ms the latency my callers will actually hear?
No. The ElevenLabs models page carries a dagger footnote on that figure stating that it excludes application and network latency. It is a model-side figure measured under conditions ElevenLabs chose, and your callers hear model time plus network time plus your own application overhead.
How low does text to speech latency need to be for a voice agent?
Human conversation sets the bar rather than any vendor. In a study of 10 languages published in the Proceedings of the National Academy of Sciences in 2009, Stivers and colleagues found an overall mode of 0 ms between turns and a cross-language mean response offset of +208 ms: see Universals and cultural variation in turn-taking in conversation. Text to speech is only one of four stages inside that budget, so a TTS figure in the tens of milliseconds is comfortable and one in the high hundreds is not.
Does Deepgram publish a latency figure for Aura 2?
Not as a headline number, but yes as a model. The Deepgram text to speech latency documentation, read on 10 September 2026, gives a non-streaming total latency of roughly 600 ms plus roughly 40 ms per 100 characters, and shows worked examples of 756 ms for a 300 character input and 879 ms for a 900 character input. The 80 ms figure on the Deepgram product page attaches to Flux TTS.
Why does my dashboard show a lower TTS latency than my callers experience?
One common cause is what your framework measures rather than what the model does. Pipecat issue 3451, opened on 14 January 2026, reported that eight WebSocket TTS integrations start the time to first byte timer only on the first request of a conversation. The maintainer disputed that reading the same day, replying that by design you get a time to first byte value for the first bot output of each turn, and the issue was closed the next day without a code change. Either way the reported figure is not a per-request measurement, so take your own from turn five onward and report P90 rather than the mean.
Does Cartesia publish a latency figure for Sonic 3.6?
Yes, but only on its marketing page. The Cartesia product page at cartesia.ai/sonic, read on 10 September 2026, states sub-90ms latency alongside 44 languages, which is the Sonic 3.6 specification. The Sonic 3.6 documentation page and the Cartesia pricing page, both read the same day, carry no millisecond figure. The only documented sub-90ms figure belongs to Sonic 3.5, which is now listed under older models. So the number exists, but not where a procurement review would look for it, and it comes with no stated metric or transport.