Performance you can verify.

4.76% across the telephony/accented corpus; 0% on clean audio. Live round-trip WER on clean audio measured 1.59%.

In plain terms: Word Error Rate is the share of words the transcript gets wrong (substituted, dropped, or inserted). Under 5% is roughly human-parity for clear speech; we hold that bar on real 8 kHz phone audio, which is the hard case. The top STT models all cluster at 2-5% WER on clean English, accuracy is table stakes, so we lead on latency and billing, not an accuracy crown.

~185 ms (185-205 ms band) to the first partial transcript on real speech, in-region. The first partial is revisable, it's stable_text that firms up as more audio arrives, not a final. Sits inside Deepgram's published 150-300 ms interim band, the same fast class. Kept separate from batch throughput below, different metric, different thing.

In plain terms: On a live call this is how quickly the agent starts 'hearing' words, which is what lets it endpoint and barge-in on time. Early in-region measurement, not an SLA, a laptop adds ~250-300 ms of round-trip on top.

92-247× real-time on the async batch tier, in-region, an hour of audio transcribes in well under a minute. This is a throughput number and is deliberately NOT blended with the streaming first-partial latency above; they measure different things.

In plain terms: Real-time factor is how many seconds of audio you transcribe per second of wall-clock. 100× means a 100-minute recording is done in about a minute. It's about clearing archives fast, not about how snappy a live call feels.

~53 ms to first audio byte on the warm path, ~98 ms cold, in-region (n=5). This is the first audio byte, not the first spoken word. A cloned voice streams its first byte in ~32 ms warm via the per-voice prefix cache. Under load on a shared/sandbox key the path can queue, a capacity fix tracked separately; it does not change the warm-path figure.

In plain terms: Time-to-first-byte is how long until the caller hears the first sound. Streaming it from the first byte (instead of waiting to render the whole clip) is what makes a voice agent feel responsive rather than frozen. Sub-100 ms is imperceptible, this puts Speak in the fastest class alongside Cartesia and ElevenLabs Flash, measured in-region.

Every requested container and sample rate is honored exactly, a hard contract check across wav @24kHz, pcm @8kHz, and g711_ulaw @8kHz.

In plain terms: When you ask for 8 kHz μ-law for Twilio, you get exactly that, not a resampled surprise. 100% means the audio drops into your telephony pipeline without a conversion step.

Median ~390 ms voice-to-voice, from the moment the caller stops speaking to the first byte of the agent's reply, measured in-region. This is human conversational pace, not a latency record; raw S2S models can be quicker. Early in-region measurement, not a guaranteed SLA. Continuously tracked by pyai-latency-30m.

In plain terms: This is the number that defines how human the agent feels. ~390 ms sits inside the natural pause between people talking; above ~800 ms it starts to feel like a walkie-talkie. We measure utterance-end to first audio in-region; a laptop adds ~250-300 ms of round-trip on top, and anchoring on session-open would inflate it by the length of what the caller said.

Composite 0-100: interruptions 40% + missed-response 40% + latency 20%. 94.3 reflects low false-barge and missed-response rates alongside the turn latency.

In plain terms: A single number for 'is this a good voice agent.' It penalizes talking over people (interruptions), failing to reply (missed responses), and lagging, the three things that make a call feel broken. Above 70 is good; we're at 94.

9 of 10 answers were both grounded in the bound knowledge base and keyword-correct.

In plain terms: When the agent answers, does it answer from your content (not made up), and is it right? 90% means it pulls the answer from your knowledge base and gets it correct nearly every time.