How to choose a low-latency TTS API for voice agents in 2026

SpeechifyAI’s Simba 3.2 reached first audio in a median of 106 ms on Coval’s independent benchmark over the 24 hours to 24 September 2026, and 123 ms on Voice Arena’s US English board that day (Coval snapshot, Voice Arena snapshot). In our own round on 9 October 2026, which timed six providers from the same client, it reached first audible audio in a median of 47 ms from US East and 145 ms from Zurich, where ElevenLabs Flash v2.5 reached it sooner, at 142 ms (our snapshot). For a voice agent, choose on time to first audio measured from where your users are, because it counts to the first sample a caller can hear and time to first byte does not.

This guide is for choosing a text-to-speech API when the job is a voice agent, not narration. A caller hears every millisecond before the first word, so the first question is how soon the audio starts, and the second is whether it stays that way under your traffic. Below: what to measure, what two independent benchmarks read on the same day, what we measured ourselves from two places, and what cuts the wait on your side.

What to measure

Time to first audio, not time to first byte

Time to first byte stops the clock when the first audio data arrives, whether or not it can be heard. Time to first audio stops it at the first sample a listener can hear. The difference is any silence at the start of the stream, and it varies by provider, voice and text.

Coval’s methodology counts that silence explicitly:

TTFA = (first audio chunk arrival - synthesis start) + leading silence inside the stream before the first audible sample

Coval, benchmark methodology

The leading silence is found with an RMS threshold over 10 ms frames of the decoded audio (methodology). A provider that sends its first byte early but opens the stream with silence gets no credit for the silence, which is the right incentive for a voice agent.

Where you measure from

Every request pays at least one network round trip to wherever the provider serves it. As of September 2026, every request to the SpeechifyAI API is served from US East, and in our measurements that month the round trip was about 35 ms from the central US and about 100 ms from central Europe (latency guide). Coval’s workers run in us-east-1 (harness README), the same part of the US our API is served from, so a caller farther away should expect to add their own round trip to Coval’s reading. Voice Arena measures from its own runner, with its own client, texts and voices.

Warm and cold connections

A new connection pays for DNS, TCP and TLS before the request is even sent. Coval opens its connection once per run and reuses it, so its numbers leave that setup out for every provider (methodology). Your agent should do the same: create one HTTP client at startup and reuse it, and HTTP/2 lets concurrent streams share one connection. If you benchmark cold requests, compare cold with cold.

Percentiles, variance and concurrency

A single fast sample tells you little. Send at least 20 requests with varied text, discard the first one or two, and report p50 and p90, not the average or the best run. Then repeat at the concurrency you expect. Coval’s loop runs at a concurrency of 8, with each model serving one request at a time, and your own traffic may look nothing like that. On the SpeechifyAI API, a request beyond your plan’s concurrency limit returns 429 rather than a slower response, so a load test shows the limit as errors, not as latency.

What two independent benchmarks read

The two boards below measured on the same day with different runners, clients, texts and voices, so the same model reads differently on each. Simba 3.2 read 123 ms on Voice Arena and 106 ms on Coval (Voice Arena snapshot, Coval snapshot). Read both, then measure from where your users are.

Voice Arena, US English, 24 September 2026

Voice Arena gives 14 of the 20 models on its US English board a latency reading. On 24 September 2026, Simba 3.2’s median of 123 ms was the lowest of them, ahead of Inworld’s Realtime TTS 2 Research Preview at 168.5 ms and Gradium’s TTS at 236 ms (snapshot). On the same board Simba 3.2’s quality rank is 7 of 20, with a rank range of 6 to 8.

Coval, 24 hours to 24 September 2026

Coval runs its open-source harness against every provider on its board every 30 minutes. Over the 24 hours to 24 September 2026, its medians spread from 48 ms to 892 ms across 30 models, and Simba 3.0 and Simba 3.2 read 102 ms and 106 ms (snapshot).

Two boards, two orders. On 24 September 2026, Gradium read 48 ms on Coval and 236 ms on Voice Arena, and Simba 3.2 read 106 ms and 123 ms (Coval snapshot, Voice Arena snapshot). Where and how a board measures changes the order, and Simba 3.2 reads between 100 and 125 ms on both.

Of the other providers’ models that were faster than Simba 3.2 on Coval that day, the two that Artificial Analysis also rates, Gradium’s undated beta and Inworld’s TTS-2 Flash, both scored lower with listeners and cost more per character (23 September 2026, Artificial Analysis snapshot).

What we measured ourselves, 9 October 2026

On 9 October 2026 we timed 13 streaming endpoints from six providers with one open script, from a Google Cloud VM in US East and one in Zurich at the same time (summary, every request, the script). Every endpoint read the same 12 sentences from the same client, and each table counts both to the first byte and to the first audible sample, the one a caller hears.

From US East, Simba 3.2 reached first audible audio in a median of 47 ms over its WebSocket input stream and 64 ms over its HTTP stream, the lowest of the 13 endpoints we timed there; the nearest was Deepgram Aura-2 at 86 ms, over HTTP with its requests sent back-to-back (summary).

From Zurich it was not the lowest: ElevenLabs Flash v2.5 over HTTP reached first audible audio in 142 ms, against 145 ms for our WebSocket input stream (summary). Our API is served from US East only, and from Zurich our server’s own share of the HTTP stream’s first byte was a median of 39 ms of the 143 ms, by its Server-Timing header; the rest was the network between Zurich and US East.

US East, warm connections

US East, cold connections

Zurich, warm connections

Zurich, cold connections

Where a competitor was faster

Every column on which another provider’s endpoint beat both of ours, compared with our two endpoints as timed in the same window (summary):

• US East, warm connections. ElevenLabs Flash v2.5 finished a sentence sooner over its WebSocket input stream: a median total of 211 ms against our 232 ms, and 226 ms with auto_mode against our 242 ms in the second window.
• US East, cold connections. ElevenLabs Flash v2.5’s WebSocket input stream finished sooner, a total of 252 ms against our 260 ms.
• Zurich, warm connections. ElevenLabs Flash v2.5 over HTTP reached first audible audio in 142 ms against our 145 ms, and sent its first byte in 120 ms, 134 ms at the 90th percentile, against our 135 ms and 151 ms. Cartesia Sonic 3.6 sent its first byte sooner over HTTP, 102 ms and 145 ms at the 90th percentile, and over its WebSocket, 101 ms and 127 ms, though 130 to 140 ms of leading silence put its first audible audio at 233 ms and 238 ms. Deepgram Aura-2’s WebSocket had a lower 90th percentile first byte, 145 ms. With auto_mode, ElevenLabs’ socket sent its first byte in 115 ms, 126 ms at the 90th percentile, against our 134 ms and 148 ms in the second window. All three ElevenLabs endpoints finished sooner: totals of 228 ms over HTTP and 181 ms over the socket against our 333 ms, and 189 ms with auto_mode against our 330 ms.
• Zurich, cold connections. ElevenLabs Flash v2.5 reached first audible audio in 166 ms over HTTP, 195 ms at the 90th percentile, and 171 ms over its socket, against our 191 ms and 200 ms. Its first byte was 146 ms over HTTP, 189 ms at the 90th percentile, and 150 ms over its socket, 162 ms at the 90th percentile, against our 181 ms and 190 ms, and its totals were 245 ms and 224 ms against our 398 ms. Cartesia Sonic 3.6 over HTTP sent its first byte in 169 ms against our 181 ms. With auto_mode, ElevenLabs’ socket sent its first byte in 156 ms against our 168 ms, and finished at 226 ms against our 403 ms, in the second window.

No endpoint opened with less leading silence than Simba 3.2’s median of 10 ms, from either place, warm or cold (summary).

Inworld, on Coval’s board

Inworld is not in our round. Coval measures it every day, so the figures below are Coval’s. Over the 24 hours to 9 October 2026 11:00 UTC, Coval read Inworld’s inworld-tts-2-flash at a median of 62 ms to first audio and inworld-tts-2 at 146 ms, against 109 ms for Simba 3.2 and 98 ms for Simba 3.0 (Coval snapshot). On Coval’s board that day, Inworld’s Flash model reached first audio sooner than both Simba models, and so did Fluxions’ vui, Gradium’s gradium-tts-beta-202609 and Nari’s qwen3-tts-fast. Palabra’s palabra-tts-v1, at 101 ms, was ahead of Simba 3.2 but not Simba 3.0.

How we measured

• Same client, same sentences. Every endpoint read the same 12 sentences of 76 to 102 characters, the kind a support agent says, as 24 kHz 16-bit mono PCM, from one Python client: httpx over HTTP/1.1 without compression, and websockets. Each pass took the endpoints in a fresh shuffled order, so every provider shared each minute. The voices are in the summary: geffen_32 for Simba 3.2, and one fixed voice for every other model.
• First audible audio. The first 10 ms window whose RMS level passes -45 dBFS, at the later of two times: the first audio chunk’s arrival plus the silence before that window, and the arrival of the chunk carrying it. Leading silence is the audio before that window. A player that waits for a late chunk hears the window later than that when the late chunk also carries silence before it, which cannot happen when the window comes in the first chunk. It did in every request to both of our endpoints and to ElevenLabs’ socket, and over ElevenLabs’ HTTP stream the chunk carrying it arrived within 1 ms of the first; for Cartesia, Deepgram, OpenAI and Gemini the figures here are the earliest a listener could have heard it. The script now follows the player through every chunk. In a follow-up check from Zurich, 20 warm requests to every endpoint but ElevenLabs’ socket at 11:55 to 12:02 UTC, that moved 4 of the 20 readings for OpenAI’s gpt-4o-mini-tts, by up to 330 ms, and none of the other 200.
• Total. When the response ended: the completion message on our socket, Cartesia’s and Deepgram’s, and the end of the body over HTTP. ElevenLabs’ socket sends no completion message, so its total is its last audio, which is why it could finish before its first audible sample would play: it sent most sentences in one message. In the follow-up check the last audio came a median of under 3 ms before the end on every endpoint but Cartesia’s, at 6 and 9 ms, and Gemini’s, at about a second, because its stream stays open after the audio.
• The threshold moves the order. Counting first audible audio as the first audio chunk plus the silence before each level, in the main window’s warm requests: at -35 dBFS our two endpoints still come first from US East, and our WebSocket input stream first from Zurich. At -55 dBFS, which counts quieter sound as audible, our WebSocket input stream still comes first from US East but Deepgram’s back-to-back HTTP moves ahead of our HTTP stream, and from Zurich ElevenLabs over HTTP and Deepgram’s WebSocket both come before ours. The raw rows carry each request’s silence at all three levels.
• Warm and cold. Each endpoint got 2 discarded warm-up requests, then 60 warm requests over one kept-open connection, then 12 cold requests that each opened a new connection inside the clock, 6 in the second window.
• Deepgram. Its HTTP API closes a connection left idle for under 20 seconds, so its HTTP requests ran back-to-back after the round-robin, with no idle time between them, which favours it. Its DNS answers rotate among addresses with very different round trips, so its rows depend on where each connection landed; the raw rows record every address.
• Our WebSocket’s limits. A session ends after 60 seconds with nothing to speak and stops taking text after 5 minutes, so the script opened a new session, outside the clock, once a session was 4 minutes old: 7 times from US East and 8 times from Zurich, across both windows.
• ElevenLabs’ socket. The main window used its default settings, with a flush after each sentence. ElevenLabs documents auto_mode for text sent as whole sentences, so a second window timed it beside our two endpoints, with 6.5 seconds after each request to keep every connection’s idle time near the main window’s. ElevenLabs served US East from us-central1 and Zurich from europe-west4, by its x-region header.
• The machines. The US East VM ran nothing but the script. The Zurich VM was also running other work: during the round its event loop woke a median of 0.16 ms late and 5.5 ms late at the 99th percentile, against 0.35 ms at the 99th percentile on the US East VM.

What cuts the wait in a voice agent

The text-to-speech API is one stage of several. Between the caller finishing a sentence and hearing the reply sit end-of-turn detection, the final transcript, the LLM’s first tokens, the text-to-speech first audio and the telephony or playback buffer. Time each stage separately for the whole turn, then work on the largest.

For the text-to-speech stage:

• Stream, do not batch. POST /v1/audio/stream sends audio as it is generated, while POST /v1/audio/speech responds once the whole clip exists, so its first audio waits for its last (streaming guide).
• Start on the first sentence. Send each complete sentence of the LLM’s reply as soon as it exists and play the streams in order. Split at sentence ends: splitting inside a sentence changes how it sounds.
• Keep the connection warm. One client for every request, opened at startup, so no caller pays for a handshake.
• Run near the API. Our API is served from US East, so an agent running there skips most of the round trip.
• Ask for PCM. audio/pcm at 24 kHz is the model’s native output and needs no encoding or decoding step.
• Play the first chunk. A player that fills a buffer before it starts adds that buffer to what the caller hears.

The latency guide covers each of these in more depth. It also explains our own first byte, which is a different measurement from the benchmarks above: 56 ms at the median and 102 ms at the 90th percentile on our production US East streaming path on 15 September 2026, from admitting the request to writing the first audio byte.

Trade-offs beyond the first audio

Latency decides whether a caller waits; the rest decides whether the agent is worth calling.

• Languages. simba-3.2 is English only. simba-3.0 covers English, German, Spanish, French, Italian and Brazilian Portuguese, and Coval read it at 102 ms on the same day (snapshot). Our multilingual model covers 48 languages, available on request through our team (language support).
• Pacing control. In the same streaming request, Simba 3.2 applies SSML <break> pauses and <prosody rate> speaking rate (SSML).
• Cost at volume. Simba 3.2 costs $10 per million characters on Starter, $8 on Pro and $6 on Scale. What 1M, 10M and 100M characters a month cost across 13 APIs is in our TTS API pricing comparison.
• Consistency under load. A median hides the slow tail. Ask for p90 or p95 at your own concurrency, and watch how the numbers move across days, not one afternoon.

Measure it yourself

The loop below streams 20 requests over one reused connection and reports two numbers: the time to first byte, and the time to first audio. It finds the first audible sample the way Coval’s detector does, as the first 10 ms window whose RMS level passes 1% of full scale. Coval adds that sample’s offset to the first chunk’s arrival; the loop plays the chunks in order and waits whenever the next one has not arrived, so a stream that stalls before the sample reads as late as a listener would hear it. It is plain HTTP, so the same loop works against any provider’s streaming endpoint once you change the URL, headers and body.

# pip install requests
import array
import math
import os
import statistics
import time

import requests

URL = "https://api.speechify.ai/v1/audio/stream"
RATE = 24_000  # audio/pcm: signed 16-bit little-endian mono at 24 kHz
session = requests.Session()  # one connection, reused
session.headers["Authorization"] = f"Bearer {os.environ['SPEECHIFY_API_KEY']}"


def first_audible_sample(pcm: bytes) -> int | None:
    samples = array.array("h", pcm[: len(pcm) // 2 * 2])  # native byte order: little-endian on x86 and ARM
    window = RATE // 100  # 10 ms
    for start in range(0, len(samples), window):
        frame = samples[start : start + window]
        if math.sqrt(sum(s * s for s in frame) / len(frame)) > 0.01 * 32768:
            return start
    return None


def heard_at(arrivals: list[tuple[float, int]], byte: int) -> float:
    # Playback starts on the first chunk and waits whenever the next chunk is late.
    played, begin = arrivals[0][0], 0
    for arrived, end in arrivals:
        played = max(played, arrived)
        if end > byte:
            return played + (byte - begin) * 1000 / (2 * RATE)
        played += (end - begin) * 1000 / (2 * RATE)
        begin = end
    raise ValueError("byte is past the end of the audio")


def measure(text: str) -> tuple[float, float]:
    start, arrivals, audio = time.perf_counter(), [], bytearray()
    body = {"input": text, "voice_id": "geffen_32", "model": "simba-3.2"}
    with session.post(URL, json=body, headers={"Accept": "audio/pcm"}, stream=True, timeout=30) as r:
        r.raise_for_status()
        for chunk in r.iter_content(chunk_size=None):
            audio += chunk
            arrivals.append(((time.perf_counter() - start) * 1000, len(audio)))
    first_byte = arrivals[0][0]
    sample = first_audible_sample(bytes(audio))
    if sample is None:
        return first_byte, float("nan")
    return first_byte, heard_at(arrivals, sample * 2)


for n in range(2):
    measure(f"Opening the connection, request {n}.")  # not counted

results = [measure(f"Your order {1000 + n} shipped this morning and arrives on Thursday.") for n in range(20)]
for label, values in (("first byte", [r[0] for r in results]), ("first audio", [r[1] for r in results])):
    deciles = statistics.quantiles(values, n=10)
    print(f"{label}: p50 {deciles[4]:.0f} ms, p90 {deciles[8]:.0f} ms")

Run it from where your agent will run, at the hour your traffic peaks. The Server-Timing header on each response reports our share of the wait, and the latency guide shows how to read it.

Rerun our round

The script behind our 9 October round is the long form of this loop, in one file: bench.py. It times every endpoint in the tables above, warm and cold, in a shuffled round-robin, finds the first audible sample at -45 dBFS rather than 1% of full scale, and writes every request to a CSV in the shape of our raw rows, with the last audio’s arrival beside the total.

python3 -m venv .venv && . .venv/bin/activate
pip install httpx==0.28.1 websockets==17.1 numpy==2.5.3
export SPEECHIFY_API_KEY=...  # plus any of CARTESIA_, DEEPGRAM_, ELEVENLABS_, OPENAI_ and GEMINI_API_KEY
python bench.py net           # each provider's address, TCP and TLS time from this machine
python bench.py run --vantage my-laptop --out results.csv
python bench.py summarize results.csv

An endpoint whose key is not set is skipped, and the file’s opening comment lists the commands for our two windows and what changed in the script after them. Run it on a machine in each place your callers are, at the same time, as we did.

Create a free API key and run the loop against your own text.