Gradium Holds the Call. A Batch TTS API Renders the Rest.

Gradium publishes a number that is hard to argue with. On the Coval production benchmark, over 750 runs on 4 May 2026, their TTS records a time to first audio of 155 ms at P50, the lowest of the nine models tested, alongside a 3.3% word error rate that was the lowest of eight.

So we went and measured what a text to speech call actually costs when an agent makes one the ordinary way, as an HTTP request that returns a finished audio file. Ten calls, one endpoint, timed twice: once on the client, once from the run's own server-side timestamps.

The fastest of the ten took 3.05 seconds.

elevenlabs /text-to-speech, 112 characters, n=3 per model

                       wall clock          server side
flash v2.5        3.12 / 3.05 / 3.49   1.59 / 1.61 / 2.02
multilingual v2   3.80 / 4.52 / 3.80   2.38 / 2.43 / 2.30

That is not a story about one vendor being slow. It is a story about what a request/response endpoint can and cannot do, and it explains why a voice agent and a voice renderer are two different purchases.

Fair disclosure. You are on the Monid blog, Monid sells the endpoint that produced those timings, and Gradium is a content partner. Gradium is not in the Monid catalogue. Every Gradium figure above is quoted from their own published benchmark with the sample size and date attached, and we did not re-test any of it. The section near the end says when none of this is worth doing.

Why does a fast model still take three seconds?

Because almost half of the wait has nothing to do with the model.

Where the three seconds go

Every run carries its own createdAt and completedAt, so the generation time can be subtracted from the wall clock the caller experiences. Across all ten calls the difference sat between 1.42 and 2.49 seconds, with a median of 1.51.

That 1.5 seconds is request routing, provider handshake, the audio being written to storage, and a signed download link coming back. It is the same 1.5 seconds whether the model spends 1.6 seconds generating or 6.4. On the shortest, fastest call in the set, the overhead was almost exactly as large as the generation itself: 1.59 seconds of model, 1.53 seconds of everything else.

This is the part that surprises people who have only read model benchmarks. Halving your model's inference time on a short utterance moves the total by well under a fifth, because the floor underneath it does not move at all.

The number that does not exist on a batch endpoint

Here is the more important point, and it is the reason the comparison at the top is not apples to apples.

Gradium's 155 ms is a time to first audio. Our 3.05 seconds is a time to the complete file. Those are different measurements, and the honest way to put it is this: a batch endpoint has no time to first audio at all. There is no first audio event to measure. Nothing arrives until everything arrives, because the contract of the call is one request, one finished MP3.

You cannot tune your way to a first-audio number on that architecture. It is not a slow version of streaming, it is a different thing, and every millisecond a streaming engine saves before the first phoneme is a millisecond the batch shape structurally cannot save.

What does the wait actually scale with?

Two variables, and the one most teams tune is the weaker of the two.

The length ladder

Holding the model at the fast one and growing the text:

eleven_flash_v2_5              wall      server
   120 characters              3.27       1.75
   500 characters              3.87       2.35
 2,000 characters              7.24       5.76

Fit a line through the server-side column and the shape falls out cleanly: roughly 1.5 seconds of fixed cost plus about 2.1 ms per character. That is a rule of thumb you can budget with. A 600-character paragraph lands near 2.8 seconds of generation. A 5,000-character chapter, which is the per-call ceiling on this endpoint, lands somewhere near 12.

Longer scripts, incidentally, have to be split across calls anyway. The endpoint caps a single request at 5,000 characters, so anything book-length is a queue of calls, not one long wait.

The model costs more than the length

Now change the model instead of the text:

                          characters    server side
multilingual v2                  500           6.35
flash v2.5                     2,000           5.76

Read that twice. The quality model on 500 characters is slower than the fast model on four times as much text. Running the same per-character fit on the quality model gives about 10.3 ms per character against the fast model's 2.13, a gap of roughly 4.8x, on an identical fixed overhead.

So the two models are not "fast" and "slow" in a general sense. They have the same floor and a five-fold difference in slope. On a one-line notification the gap is under a second and you should take the better voice. On a two-minute narration it is the difference between a pause and a coffee break. The fast model also bills at half the rate of the quality one, which means the cheaper choice is the faster choice on this endpoint, and that is not always true elsewhere.

Which voice jobs need a streaming layer, and which do not?

Split the work by whether a human is waiting mid-sentence.

The conversation side

If someone is on the phone, or talking to an agent that has to stop when they interrupt, the whole product lives inside the first few hundred milliseconds. A 1.5 second floor is not a rough edge there, it is the difference between a conversation and a walkie talkie. This is the job Gradium is built for, and where its published first-audio figure is the metric that matters. Their documentation covers the streaming side directly, including semantic voice activity detection and flush on the transcription path, which is the machinery that makes turn-taking feel natural rather than merely fast.

It is worth naming the thing this does not depend on: model quality. A slightly worse voice that starts immediately beats a better voice that starts late, every time, because the listener is judging the silence, not the timbre.

The rendering side

Now the opposite job. You have 400 product descriptions to narrate overnight, or a weekly digest to voice, or a short-form video pipeline that needs a track per clip. Nobody is waiting. The 1.5 second floor is paid 400 times in a batch that runs while you sleep, which makes it irrelevant, and the only things that matter are voice quality, per-character cost and whether the job can run unattended.

That is the shape a request/response endpoint is good at, and it is the shape the speech endpoints on Monid expose. One request, one finished file, a signed link, a per-character line on the bill. For picking which vendor's voice to render with, the text to speech comparison does that job properly and this piece deliberately does not repeat it.

One clarification the honest version of this argument requires: ElevenLabs itself ships a streaming API. Nothing measured here says otherwise. What we measured is the batch endpoint shape, and the finding is about that shape rather than about that vendor.

How do you keep the rendering side from becoming five vendors?

The failure mode is not latency, it is a drawer full of API keys.

One balance, several voices

Voice work rarely stays on one provider. A team ends up on one vendor for English narration, another for a language the first one handles badly, a third for sound effects or music under the track. Each arrives with its own signup, its own minimum, and its own monthly plan that sits idle between bursts, which is exactly the mismatch metered calls rather than a standing subscription exists to fix.

Monid is the OpenRouter for agent tools: one key, one balance, discovery and execution across the catalogue without a separate contract per vendor. That is the same argument as models and tools being two different integrations, applied one layer down. A voice layer for the conversation is a third integration again, and pretending it is the same purchase as batch rendering is how teams end up paying realtime prices for overnight work.

The billing unit matters more than the headline rate here, and speech is unusual in that the unit is legible. Text to speech bills per character, which you can count before you call, so a narration budget is arithmetic rather than a forecast. That is not true of most endpoints, where you find out what a job cost after it ran. It does mean the model choice is a budget decision as well as a latency one: the fast model bills at half the rate of the quality model and generates roughly five times quicker, so on long-form work the two axes point the same way for once. Current per-endpoint figures live at monid.ai/tools, which stays accurate in a way a number typed into a blog post does not.

If the wiring question is the one you actually have, MCP versus a plain API call covers who does the wrapping, and the tool layer an agent reaches through covers the discovery half.

When is none of this worth doing?

Three cases, and they are more common than the vendor pages suggest.

When text is the product

Most agents do not need a voice. A support agent in a chat window, a coding agent, a research agent writing a report: adding speech to any of these is a demo feature that costs money per character forever. If the output is read rather than heard, the correct number of TTS calls is zero.

When you only need it once

For a single voiceover, a one-off narration, or a prototype, the fastest path is a web interface and a download button. Wiring an endpoint, handling the 5,000-character split and storing the returned links is engineering that pays back over hundreds of calls and never pays back over three. Giving a product a lifelike voice is worth doing when it is a product surface, not when it is a one-time asset.

When the endpoint you already have is the wrong shape

The third case is the one worth flagging to anyone about to build a phone agent on a batch endpoint because it was already in the stack: do not. The floor measured above will not move, and no amount of prompt engineering or model swapping will get a request/response call to behave like a stream. Teams try anyway, usually by chopping the reply into short sentences and firing them off one at a time so that playback can start on the first fragment. It half works, and the price is steep. Against the numbers above, a 500-character reply split into five 100-character calls starts speaking after about 1.7 seconds instead of 2.6, which is a real gain of under a second, but the fixed overhead is now paid five times, so the full reply takes roughly 8.5 seconds end to end instead of 2.6. You have bought a slightly earlier first word with six extra seconds of total latency, and any pause between fragments lands in the middle of a sentence.

The tell that you are in this case is that you are optimising the wrong number. If the metric you care about is how long the listener waits before hearing anything, no property of a batch endpoint is the lever, and the work belongs on a streaming layer instead.

Conclusion

Ten calls, one endpoint, and three numbers worth keeping.

A batch text to speech call carries about 1.5 seconds of fixed overhead that no model choice touches. On top of that it adds roughly 2.1 ms per character on the fast model and 10.3 ms on the quality one, which is why the quality model on a short paragraph loses to the fast model on four times the text. And the metric a streaming engine competes on, time to first audio, does not exist on this shape of API at all, which is the actual reason a conversational agent and a narration pipeline are two different purchases rather than two settings of one.

Buy the streaming layer for the conversation. Meter the rendering. They are not competing with each other.

FAQ

Last updated August 2026.