One API for every voice provider — with the traps already mapped.
Speko routes each call to the best STT → LLM → TTS stack and flags failure modes like this one before they hit production. You build the agent; we handle the provider maze.
Start building on Speko →
Explore the TTS benchmark →
---
## The Pause Is the Hard Part: How We Stopped Cutting Callers Off
- Date: 2026-07-05
- Canonical: https://benchmarks.speko.ai/blog/how-speko-uses-smart-turn
- Description: The single thing that makes a voice agent feel robotic is getting cut off mid-thought. Here is exactly how Speko runs Smart Turn on live calls to decide when a caller is actually done — the threshold, the context-conditioning, the guards — and the measured proof that it works.
Ask anyone who has talked to a voice agent what makes it feel like a machine. It is almost never the voice. It is the interruption — you take a breath in the middle of a sentence and the agent barges in over you, answering a question you had not finished asking.
That failure has a name: a **false cutoff**. It is the most damaging error in a live call, and it is entirely a turn-taking problem. The agent has to answer one deceptively hard question after every pause: *is the caller done, or just thinking?*
This is how we answer it.
## Why the obvious approaches don't work
The naive version is a **silence timer**: wait N milliseconds of quiet, then talk. This is what a raw VAD (voice-activity detector) gives you, and it is hopeless. A person pausing to think and a person who has finished both produce silence. Tune the timer short and you trample every hesitation; tune it long and the agent feels laggy and *still* cuts off the slow talkers. On our own turn-taking benchmark a VAD-plus-timer ends **every** turn — a 100% false-cutoff rate. It is the floor, not a solution.
The next idea is to read the **words**. Feed the running transcript to a small language model and ask "does this look like a finished sentence?" This works surprisingly well for clear incompletes — "I was thinking maybe we could" is obviously unfinished — and models like LiveKit's turn-detector and Turnsense score well on it. But it has two problems in a real call. It can only run *after* speech-to-text produces the transcript, so it inherits the STT's latency. And words lie: "Okay, so my account number is four one—" is a complete-looking clause right up until it isn't.
The signal that actually separates *done* from *thinking* is **prosody** — the pitch, energy, and final lengthening of human speech. Humans hold the turn on sound, not grammar. So that is what we run.
## What we actually run
Speko uses [Smart Turn v3.2](/#turntaking), Pipecat's open-source audio turn-detection model. Three decisions matter:
**It runs in-process.** The model is an ~8 MB ONNX file baked into the worker image and executed via `onnxruntime-node` — no network hop. About 55 ms of local CPU per turn. We used to host it as a remote endpoint and paid 200–800 ms of round-trip for the privilege; moving it in-process deleted that.
**It listens to audio, not text.** We tee the caller's audio stream into a rolling 8-second, 16 kHz buffer. When the VAD detects end-of-speech, the model reads that buffer and returns one number: **P(the turn is complete)**. Because it works on the audio directly, it runs *in parallel* with STT instead of waiting behind it — it decides first.
**It gates, it doesn't trigger.** VAD detecting silence starts the clock; Smart Turn decides what to do with it. If the probability clears the threshold, the turn commits. If it doesn't, we **HOLD** — keep the mic open and extend the wait.
## The stack that kills false cutoffs
Getting from "we run a good model" to "callers stop getting cut off" took a series of specific, boring fixes. Each one is a lever against the same failure.
**The threshold is 0.85, not 0.5.** This is the single biggest one. The model's stock decision boundary is 0.5. On live calls that was a disaster: on 2026-06-17 we watched borderline turns score p ≈ 0.76–0.83 and *commit* — the model was 76% sure the caller was done, so it talked over the 24%. Clearly-finished turns sit above 0.95. Raising the bar to 0.85 leans the whole system toward patience.
**The threshold bends to the question.** A flat threshold is still wrong, because the *right* amount of patience depends on what you just asked. After a yes/no question we drop the bar (−0.25) — the answer ends cleanly, so commit fast. After an open-ended question we raise it (+0.05), and after one that invites a number or an address — "what's your phone number?" — we raise it more (+0.07), because people deliver those in chunks with pauses in between. This context-conditioning is on by default.
**Under the threshold, we wait — up to a point.** A held turn extends toward a `maxDelay` of 1.5 s rather than committing at the ~600 ms floor. That ceiling used to be 3 s, which created so much dead air that callers started talking again out of confusion — so patience has a limit too.
**Guards catch the model's own mistakes.** Smart Turn under-scores some genuinely complete utterances — a crisp "305, this is Jenny." can land at p ≈ 0.63. So a text guard commits a clearly-finished sentence anyway — *unless* the audio strongly vetoes it (p below 0.35), which means a real mid-thought continuation is happening and the words are lying.
**Barge-in is a clean interrupt.** When a caller talks over the agent, we kill the agent's audio at the source and — critically — never replay the buffered tail. The framework default pauses and resumes, replaying the half-sentence the caller just interrupted; those replayed fragments are exactly the "why is it still talking?" moments. We turn that off. And after a barge-in, we suppress the fast-commit guards so the agent waits for the caller's *real* turn-end instead of pouncing on their first word.
## Does it actually work? The numbers.
Mechanisms are easy to describe and easy to fool yourself about. So we measured it on live traffic.
Every turn logs the probability and the verdict. A turn where the model scores **between 0.5 and our threshold** is one the *stock* model would have committed on — a cutoff — but ours HOLDs. That is a directly measurable "false cutoffs prevented" rate.
Over **3,742 turns across live calls** in the last 30 days: **6.5%** fell in that danger band — roughly one turn in fifteen that the stock 0.5 threshold would have cut off, held instead. Another 23% are genuine mid-thought holds (both thresholds agree to wait), and 5.7% are the *opposite* save — turns the model under-scored that our guards committed, preventing dead air rather than a cutoff.
The threshold distribution shows the context-conditioning working in the wild: most English turns run at 0.85, but 772 of them were raised to 0.90–0.92 (open and number-taking questions) and a slice dropped to 0.5–0.67 (closed questions and Spanish).
One turn in fifteen sounds small until you are the caller who got cut off. Across every call, on every pause, it is the difference between an agent that listens and one that interrupts.
## The honest caveat
If you look at our [turn-taking benchmark](/#turntaking), Smart Turn does *not* top the table — the text models do. That is not a contradiction; it is the measurement being honest. Our benchmark clips are synthesized speech, and text-to-speech renders even an unfinished fragment with finished-sounding prosody. An audio model correctly hears "done" because the audio *sounds* done — so a controlled dataset built from TTS structurally favors models that read the words. On real speech, where a mid-thought pause actually trails off, the gap narrows and prosody earns its keep. We run the audio model on live calls for the thing the benchmark can't stage: the human pause.
---
## LiveKit Inference for Voice Agents: Fast First Token, and the Goodbye Most Models Skip
- Date: 2026-07-05
- Canonical: https://benchmarks.speko.ai/blog/livekit-inference-for-voice-agents
- Description: LiveKit shipped an inference host. We ran it through a voice-agent lens from us-east4 — first-token latency and six dial-discipline behaviors. It's the new speed leader (gemma-4-31b-it at 92ms), and on what matters — tool-calling, not fabricating, scope, honesty, injection resistance — nearly every model is clean. The one shared blind spot is ending the call: most models hang up silently instead of saying goodbye.
LiveKit shipped an inference host — a fast, worker-level way to run open and hosted models. We put it through a voice-agent lens from us-east4, two ways: how fast it returns a first token, and how it behaves on the small disciplines a live call actually depends on. This is the LiveKit inference host measured on its own — not blended into any gateway ranking.
## First token: the new speed leader
| Model (on LiveKit) | TTFT p50 | p90 |
|---|---|---|
| gemma-4-31b-it | 92ms | 112ms |
| gpt-oss-120b | 118ms | 132ms |
| kimi-k2.5 | 167ms | 232ms |
| gemini-2.5-flash-lite | 241ms | 373ms |
| gpt-4o-mini | 366ms | 464ms |
| gpt-4.1 | 422ms | 477ms |
| gpt-4.1-mini | 524ms | 583ms |
`gemma-4-31b-it` posts the fastest first token we've measured anywhere — **92ms** — and `gpt-oss-120b` serves at **118ms**, beating the same model on Cerebras (~195ms). For a live turn, every millisecond before the agent starts speaking is silence the caller hears, so this is the difference between snappy and sluggish.
## Dial discipline: one shared blind spot
Speed is only half the turn. We ran six dial-discipline scenarios — the behaviors a phone agent lives or dies on — three times each (18 runs per model):
| Model | tool trigger | don't fabricate ID | farewell + end_call | scope refusal | robot honesty | injection resist | total |
|---|---|---|---|---|---|---|---|
| kimi-k2.5 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 18/18 |
| gemini-2.5-flash-lite | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 18/18 |
| gemini-2.5-flash | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 18/18 |
| gpt-5 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 18/18 |
| gemma-4-31b-it | 3/3 | 3/3 | 1/3 | 3/3 | 3/3 | 3/3 | 16/18 |
| gpt-oss-120b, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-5-mini | 3/3 | 3/3 | 0/3 | 3/3 | 3/3 | 3/3 | 15/18 |
Read down the columns, not across the rows. On five of the six behaviors — firing the right tool, not fabricating an ID, refusing out-of-scope requests, staying honest about being a bot, and resisting prompt injection — **every model scores a clean 3/3.** On the things that actually get an agent in trouble, LiveKit's models are disciplined.
The entire spread comes from one column: **farewell + end_call.** kimi-k2.5, both Gemini Flash variants, and gpt-5 speak a proper closing line before hanging up (3/3). gemma-4-31b-it slips once (1/3). And five models — gpt-oss-120b, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-5-mini — miss it entirely (0/3): they fire `end_call` with **empty content**, hanging up in silence instead of saying goodbye. gpt-4o-mini fails a different way — it writes the tool call out as literal text.
## What that means
It's a UX wart, not a safety hole. The model does the right thing — it just doesn't announce it, so the caller hears a click instead of "thanks, goodbye." In production you don't leave that to the model: the worker enforces a farewell so a closing line always plays, whichever model is behind it. But it's worth knowing — wire a bare model straight to `end_call` and most of them will hang up on your caller without a word.
## The verdict
LiveKit Inference is fast, and on the disciplines that matter it's clean. For the latency floor, reach for `gemma-4-31b-it` (92ms) or `gpt-oss-120b` (118ms). Just don't count on the model to say goodbye — enforce the farewell downstream.
Method: measured from us-east4 — first-token latency over 15 iterations per model; dial discipline over six scenarios, three reps each (18 runs). One measurement date, a snapshot on our rig; we publish the counts so you can weight it.
---
## Everyone Measures the Clip. Nobody Measures the Call.
- Date: 2026-07-05
- Canonical: https://benchmarks.speko.ai/blog/true-cost-per-solve
- Description: WER, MOS and time-to-first-token each score one component doing one thing once. The number that actually decides a voice agent is what one solved call costs — end to end, with the caller talking back.
Every voice-AI leaderboard measures a clip. Word Error Rate on a clean, scripted sentence. MOS on a single utterance. Time-to-first-token on one prompt. Cost-per-minute on a rate card. Each of those scores **one component doing one thing once**, on audio that behaves.
A real call doesn't behave. The caller interrupts. The line goes silent. The name is spelled out loud. The model has to decide whether to book the appointment or keep asking questions. None of that shows up on a component leaderboard — and it's the entire thing you're actually buying.
So we measured the call.
## The fabrication trap
The obvious way to score an agent is *cost ÷ resolution*: how many dollars per solved problem? Run that naively and you crown a liar. The cheapest-looking stack in our booking test resolves in **1.7 turns** — because the model confidently says "you're booked!" and hangs up without ever calling the scheduling tool. Nothing was booked. The bill is tiny. The metric loves it.
The fix is to make "solved" mean something. We wire a real `schedule_appointment` tool and count a solve **only when the tool actually fires**. Grounded resolution, not asserted resolution.
Once you do that, the ranking flips:
- The cheapest *honest* stack — Deepgram nova-3 · Cerebras gpt-oss-120b · Cartesia sonic-3.5 — solves for **$0.058** per booking, grounded 100% of the time.
- The all-brand premium stack — ElevenLabs · GPT-4.1 · ElevenLabs — costs **$0.703**. About **12× more** for the same outcome.
- Two stacks that looked cheap per-call get flagged: one grounds only 33% of the time, another never books at all. Their low bill is meaningless.
## What "cheap" hides
The spread isn't about the sticker price of any one model. It's about how many turns the agent burns, whether the LLM fires the tool under a latency cap, and whether the STT heard the caller in the first place. A "premium brain" that clarifies for ten turns is more expensive than a fast one that books in four — even if its per-token price is lower.
That's why we publish the components *and* the call. The [STT](/#stt), [TTS](/#tts), [LLM](/#llm) and [S2S](/#s2s) boards tell you where each piece stands. The [Cost / solve](/#stacks) board tells you what happens when you wire them together and let a caller talk back.
## Read the dial yourself
Speko operates the gateway these tests run through — we build voice-AI infrastructure. So every provider is measured by the same rig, on the same audio, with no preferred path, and we publish the method and the raw deltas. Where we can't measure something honestly, it shows a dash, not a guess. The point of an instrument is that anyone can read the dial.
Everyone measures the clip. We measure the call.
---
## Your Voice Agent Booked the Wrong Name. WER Said It Was 95% Accurate.
- Date: 2026-06-22
- Canonical: https://benchmarks.speko.ai/blog/stt-tool-call-corruption
- Description: A voice agent only acts on a few words in any sentence — the ones that become tool-call arguments. We measured how often real speech-to-text corrupts them, why Word Error Rate hides it completely, and the verification layer that stops an agent from silently booking the wrong name.
A restaurant's voice agent took a reservation and booked it under **Beatty**. The caller's name was **Abadi**. By the industry's favorite metric the slip barely registered — one wrong word in an otherwise clean sentence, the sort of high-nineties word accuracy speech-to-text vendors print on their landing pages. The one word it got wrong was the name, and the name was the entire point of the call.
So we measured it properly. We took ten ordinary booking sentences, synthesized them as clean studio speech — no noise, no background, no accent tricks — and ran each one through five production speech-to-text engines, then handed the result to the same language model with the same booking tool. The party sizes came through. The days came through. The times came through. The names did not.
## Hear it for yourself
Each clip below is a synthetic caller saying a perfectly ordinary sentence. The audio is crisp. Underneath is what the engines actually wrote down.