Best Real-Time Speech-to-Text APIs 2026: Latency, Stability and Cost Tested

Published on August 20, 2026 by Steven Jones

A real-time speech-to-text API has a harder job than producing an accurate transcript. It has to return text early enough to be used, keep that text stable enough for an application to act on it, decide when the speaker has actually finished, and recover cleanly when a live connection misbehaves.

This comparison is specifically for developers building voice agents, live captions, call assistance, meeting products and other streaming speech workflows. It does not rank providers on generic batch transcription. The live test is narrower: first partial latency, first usable text, transcript revision, endpointing, reconnect behaviour, overlapping speech, concurrency and the effective cost of keeping audio flowing.

The strongest choice depends on where failure hurts you. Deepgram is our first choice for conversational voice systems where turn timing is central. AssemblyAI gives developers unusually useful control over the latency-accuracy trade-off, with a much cheaper streaming tier if its lower-cost model is sufficient. Speechmatics is particularly attractive for multilingual and accent-heavy workloads. Google provides a useful stability signal to determine whether an interim transcript is safe to consume. OpenAI makes the most sense when live transcription is already part of a wider OpenAI real-time stack.

Real-time STT API winners at a glance

Best for	API or model	Why it makes the shortlist	Main live-streaming limitation	Current list-rate equivalent
Best overall for voice agents	Deepgram Flux / Nova-3	Fast streaming, dedicated turn-detection controls and a voice-agent-specific Flux path	Aggressive endpointing or eager turn detection can create false starts that downstream systems must cancel safely	Nova-3 Monolingual about $0.29/hour; Flux English $0.39/hour
Best for tunable live behaviour	AssemblyAI Universal-3.5 Pro Realtime	Latency modes, turn controls and contextual features make it easy to optimise for different conversational workloads	The flagship stream costs more than specialist budget tiers, and session-duration billing punishes sockets left open unnecessarily	$0.45/hour; Universal-Streaming value tier $0.15/hour
Best for accents and multilingual speech	Speechmatics Real-time	Strong language and accent coverage with straightforward Standard and Enhanced live tiers	Partial transcripts are mutable, so applications need a deliberate policy for revisions before triggering actions	$0.24/hour Standard; $0.43/hour Enhanced
Best for stability-aware downstream logic	Google Cloud Speech-to-Text V2	Interim results include an explicit stability value that can help gate UI updates and downstream actions	Standard first-tier pricing is materially higher than several specialist live-STT options	$0.96/hour at $0.016/minute before higher-volume tiers
Best for an OpenAI-native stack	OpenAI GPT-Live-Transcribe	Native streaming transcription fits cleanly beside other real-time OpenAI components	It is one of the more expensive base transcription options here if STT is all you need	$1.02/hour at $0.017/minute

Pricing note: rates were checked on 20 August 2026 and converted to hourly equivalents where providers publish per-minute pricing. They are useful for shortlist comparisons, not procurement quotes. Volume tiers, add-ons, regional choices, enterprise agreements and connected-session behaviour can change the effective cost.

---

---

The live metric most comparisons miss is first usable text

First-pass latency is easy to market and easy to benchmark. It is also easy to misuse. A provider can emit a fragment very quickly, then revise it several times as more audio arrives. That looks excellent on a latency chart, but it can be worse for an agent than a slightly later partial that stays correct.

Production developers keep running into the same problem: the transcript that eventually looks right is not necessarily the transcript the application had when it made its decision. A voice agent may start an LLM call, search a customer record or confirm a date from text that is replaced 200 milliseconds later. The final transcript can score well while the live system still fails.

For that reason, a useful streaming speech-to-text benchmark needs three different timestamps:

• First partial: the first non-empty hypothesis returned by the API.
• First usable partial: the first hypothesis stable enough to display, search against or use for speculative processing.
• Final or committed text: the transcript segment the provider says will no longer change.

Then measure how the text changes between them. We would track partial rewrite count, critical-entity revisions, and time to stable text alongside normal latency. A 250 ms first partial that changes a surname, phone number and appointment date before finalisation is not automatically better than a 400 ms partial that holds those entities correctly.

Seven checks make a real-time speech-to-text benchmark useful

1. Measure latency at the client, not just inside the model

Server inference time is only part of the delay a user experiences. Audio buffering, encoding, network transit, TLS and WebSocket setup, response transport and client processing all sit around it. Measure from the application boundary and report percentiles rather than one attractive best-case number.

Deepgram’s documentation on measuring streaming STT latency makes a useful separation between transcript latency and end-of-turn latency. Captioning cares about how far the text trails the audio. A voice agent also cares about how long it takes to decide that the speaker has finished. Treat those as separate measurements.

2. Count revisions, not only words

Log every interim hypothesis, not only the final transcript. Token-level edit distance between consecutive partials is useful, but critical entities deserve their own field. A changed filler word is cheap. A change in account number, medicine name, postcode, or date can trigger the wrong tool call.

A practical metric is the false commit rate: how often your application acts on an interim transcript and later has to reverse, cancel or repair that action because the text changed. This captures the cost of instability in a way word error rate cannot.

3. Test endpointing with natural pauses

Silence is not the same thing as the end of a thought. People pause while recalling a postcode, reading a card number or deciding how to phrase an answer. Set the endpoint threshold too low, and the system chops one utterance into several turns. Set it too high, and every response develops dead air.

For voice agents, include deliberate mid-sentence pauses, self-corrections and trailing phrases in the test audio. Endpoint delay should be measured from the actual end of speech to the event your application uses to start the next stage. This is often a more important interaction metric than the first transcript fragment.

4. Force a reconnect

A pristine WebSocket session hides a production failure path. Mobile connections change, proxies close idle sockets, workers restart, and network packets disappear. A reconnect test should deliberately break the stream, time the recovery, and check whether replayed audio creates duplicated words or missing text.

Do not reopen a new STT socket for every normal conversational turn unless the API specifically requires it. Connection establishment has its own cost, and repeated setup can dominate an otherwise fast recogniser. Keep a small local audio buffer, sequence events and make transcript merging idempotent so a recovered stream can replay audio without duplicating committed text.

5. Add overlapping speech and barge-in

Two people talking at once is not an exotic edge case in calls. Nor is a caller interrupting an AI response. Test cross-talk, a short acknowledgement such as “yeah” during another speaker’s turn, and a genuine interruption that should stop playback.

Accuracy alone does not tell you whether the conversational system behaved correctly. Record whether the user was detected, whether the agent stopped speaking, whether the correct speaker was associated with the words and whether the transcript after the overlap is still coherent. A recogniser can produce a respectable final transcript while the live interaction feels broken.

6. Test concurrency at the level you will actually deploy

A single development stream says little about an API serving hundreds of simultaneous calls. Concurrency limits, queueing behaviour and tail latency can matter more than the median result once traffic increases. Test at the expected steady-state load and at a short burst above it, then log p50, p95 and error rates separately.

Published limits are only the starting point. Speechmatics, for example, currently lists 50 concurrent real-time sessions on its Pro plan, while AssemblyAI advertises unlimited concurrent streams for Universal-Streaming. What matters operationally is whether latency and connection reliability remain acceptable for your own audio profile and region.

7. Calculate cost per connected live hour

Price per audio minute is not always the same as the cost of running a live product. Some workloads hold a connection open through silence. Some use paid diarisation, redaction or custom vocabulary features. Speculative LLM calls triggered by unstable partials can also turn an apparently cheap STT feed into a more expensive pipeline.

For planning, use:

effective_live_hour_cost =
  base_streaming_charge
  + streaming_add_ons
  + avoidable_idle_session_cost
  + downstream_work_triggered_by_bad_partials

The last line is easy to ignore. If a premature endpoint starts an LLM and TTS response that must be cancelled, the STT price did not change, but the cost of that transcript event did.

Deepgram is our first choice when turn timing is part of the product

Deepgram is the most natural first test for conversational AI because it now separates general streaming transcription from a voice-agent-specific model. Nova-3 is the broader streaming recogniser, while Flux is designed around conversational turn detection and interruption handling.

Flux exposes end-of-turn controls rather than forcing developers to bolt a fixed silence timer onto the recogniser. Its eager end-of-turn path can also start downstream work before the turn is fully committed. That can reduce perceived delay, but it creates a new engineering responsibility: speculative LLM work must be cancellable when the speaker resumes.

That is a useful trade-off, not a free latency win. Lowering an eager threshold can produce earlier responses and more false starts. Raising it makes the system more conservative and gives back some of the latency advantage. Voice products should tune it against their own interruption and self-correction patterns rather than copying a default from a demo.

Also, separate transcription turn detection from playback interruption. Recognising that the user has resumed speaking is only one half of barge-in. Your transport and TTS layer still need to stop or clear queued audio quickly enough so that the agent does not continue talking over the caller.

Nova-3 remains attractive for live captions, analytics and transcription where you want fast interim text without letting the STT layer own the full turn-taking decision. Current pay-as-you-go pricing is about $0.29 per hour for Nova-3 Monolingual and $0.39 per hour for Flux English before optional features.

For the wider platform, accuracy and deployment views outside this live-only benchmark; see our Deepgram review.

AssemblyAI gives you a useful latency-versus-accuracy dial

AssemblyAI is compelling for teams that want to tune live behaviour without building every control themselves. Universal-3.5 Pro Realtime exposes modes for minimum latency, balanced operation and maximum accuracy, with additional turn controls for workloads that should wait longer before committing an utterance.

This is particularly useful for entity-heavy speech. A support flow collecting an email address or account number should not use the same endpoint behaviour as a low-stakes conversational assistant. The right configuration may deliberately wait longer because splitting a long entity across turns is more damaging than adding a small pause.

AssemblyAI also has a lower-cost Universal-Streaming tier at $0.15 per hour. The flagship Universal-3.5 Pro Realtime rate is $0.45 per hour. Treat these as separate buying decisions rather than assuming the cheapest tier represents the flagship model’s live behaviour.

There is a less obvious cost issue, too: AssemblyAI documents streaming charges based on session duration, meaning the clock runs for the entire time the WebSocket is open rather than only during periods of useful speech. Make socket shutdown part of error handling. A crashed process that leaves a session alive should not become a billing problem.

Speechmatics is the strongest shortlist addition for global speech

Speechmatics deserves a place in live-STT tests where accents, multilingual speech or international deployment matter more than winning a single English voice-agent latency race. Its current Pro pricing is simple to model: $0.24 per real-time hour for Standard and $0.43 for Enhanced, billed per second, with 50 concurrent real-time sessions on the Pro tier.

The operational point to understand is partial mutability. Speechmatics can return partial transcripts quickly, but those partials can change as more context arrives. A UI can simply replace the text. A transactional voice application needs stricter rules, especially around numbers, dates and named entities.

Speechmatics also offers a 33% model-training discount for customers who opt in to allowing audio and transcripts to be used to improve its models. That can materially change the effective rate, but it is not a discount every workload should take. Data policy and procurement requirements should decide whether it is acceptable, not the headline saving.

Google Cloud STT has the cleanest signal for partial stability

Google Cloud Speech-to-Text exposes a useful feature that many integrations end up recreating themselves: a stability value for interim streaming results. It estimates the likelihood that the recogniser will revise the current hypothesis. That gives developers a direct signal for treating one partial differently from another.

For live captions, that can control when text changes from tentative to visually settled. For a voice agent, it can be one input to a speculative-processing rule. Do not treat a stability value as proof that the words are correct. It indicates how likely the hypothesis is to change, not whether the transcript is semantically correct.

Google’s V2 Standard rate starts at $0.016 per processed minute for the first 500,000 minutes in a month, equivalent to $0.96 per hour before higher-volume tiers. That is substantially above the base specialist rates in this shortlist, so the case is strongest when Google Cloud integration, deployment controls or the stability signal reduce engineering elsewhere in the stack.

For the broader managed API beyond the live-streaming focus here, see our Google Speech-to-Text review.

OpenAI GPT-Live-Transcribe makes more sense as part of a wider real-time stack

OpenAI’s current streaming transcription product is GPT-Live-Transcribe, priced at $0.017 per minute, or about $1.02 per hour. That is not the cheapest way to buy STT in isolation. Its appeal is architectural: teams already using OpenAI for real-time voice or downstream model work can keep more of the live pipeline in one ecosystem.

One comparison trap is using classic Whisper as though it were equivalent to a native real-time API. OpenAI’s API documentation explicitly says streaming is not supported for whisper-1 on the transcription endpoint. Developers can chunk audio around Whisper, but that introduces their own buffering, overlap, deduplication and endpointing logic. It is a different engineering problem from consuming a purpose-built streaming event feed.

If you already operate a local Whisper stack and can tolerate chunk-based processing, it may still be attractive on cost, control or data placement. For a new conversational product where low-latency turn handling is the priority, compare native streaming paths rather than treating every product labelled “Whisper” as the same thing.

At 1,000 live hours, list price stops looking like a rounding error

Small per-minute differences become visible quickly in a product with sustained calls or captions. The table below holds usage constant at 1,000 billable live hours and applies only the current public base rates. It excludes taxes, negotiated discounts and paid extras.

Provider / model	Base rate	Approx. base cost for 1,000 hours
AssemblyAI Universal-Streaming	$0.15/hour	$150
Speechmatics Real-time Standard	$0.24/hour	$240
Deepgram Nova-3 Monolingual	$0.288/hour	$288
Deepgram Flux English	$0.39/hour	$390
AssemblyAI Universal-3.5 Pro Realtime	$0.45/hour	$450
Google Cloud Speech-to-Text V2 Standard	$0.96/hour	$960
OpenAI GPT-Live-Transcribe	$1.02/hour	$1,020

This still does not identify the cheapest production system. A lower-rate API that causes more false commits, requires a second endpointing service or makes you over-provision around low concurrency can cost more overall. Conversely, a higher-rate API can be justified if it eliminates custom orchestration or reduces costly downstream errors.

A repeatable live-STT test should use the same audio and the same clock

Do not compare a provider from a browser demo with one from your production server. Stream the same audio from the same client region, over the same network path, using the same chunking strategy. Where providers require different codecs or sample rates, record that as part of the configuration rather than hiding it.

A compact test set should include:

• Clean close-mic speech establishes the best-case floor for latency and transcript stability.
• Telephone-quality audio: catches failures that studio microphones might miss, especially names and numbers.
• Self-corrections, such as “Tuesday, sorry, Thursday,” test whether partial consumers act too early.
• Long entities, such as email addresses, postcodes, booking references, and serial numbers, expose premature endpointing.
• Cross-talk and barge-in: tests whether live interaction survives when speakers overlap.
• Background noise reveals VAD and endpoint behaviour that clean test files miss.
• Forced network interruption: measures reconnect time, duplicate transcript handling and lost audio.

For every event, log the client timestamp and enough identifiers to rebuild the turn later:

speech_start_ms
first_partial_ms
first_usable_partial_ms
stable_text_ms
final_text_ms
end_of_turn_ms
partial_revision_count
critical_entity_revision_count
false_commit_count
socket_disconnect_count
recovery_ms

Report p50 and p95 for latency, not only the mean. A real-time product is often judged by the awkward slow turns rather than the median one. Keep transcript quality and latency side-by-side so a more aggressive configuration cannot “win” by returning the wrong text faster.

How to choose without rebuilding this comparison inside your own app

Start with Deepgram if the product is a conversational voice agent and timing, interruption handling and low latency are central to the experience. Test Nova-3 and Flux separately because they solve different live problems.

Start with AssemblyAI if you want explicit latency modes, strong control over turn behaviour, and the option to trade flagship capability for a $0.15/hour value-streaming tier. Pay close attention to the session lifecycle because open sockets affect cost.

Start with Speechmatics if the hardest part of your workload is accents, international speech or multilingual coverage rather than English-only speed. Its Standard live rate also makes it easy to justify a proof of concept.

Start with Google Cloud STT if your application already runs in Google Cloud, or use the interim stability signal to simplify downstream logic. The higher first-tier rate makes less sense if you only need a basic streaming transcript.

Start with OpenAI GPT-Live-Transcribe if transcription is one part of an OpenAI-centred real-time architecture and reducing integration surfaces is worth more than minimising the STT line item.

AWS Transcribe and Azure AI Speech remain credible enterprise streaming APIs, especially where the surrounding cloud platform drives the buying decision. They are not headline winners here because this page is deliberately focused on live transcript behaviour rather than the breadth of Cloud procurement. If your infrastructure is already committed to AWS or Microsoft, include the native service in the same client-side test before adding another vendor.

The practical winner is the API that fails safely before the final text arrives

For a live speech product, the best STT API is not simply the one with the lowest advertised latency or the cleanest final transcript. It is the one that gives your application useful text early, exposes enough signal to avoid acting on unstable words, ends turns at the right moment and survives the network conditions your users actually have.

Our default shortlist starts with Deepgram for voice-agent turn timing, AssemblyAI for tunable behaviour, Speechmatics for multilingual and accent-heavy speech, Google for stability-aware streaming logic, and OpenAI, where STT belongs inside a broader OpenAI real-time stack.

Before choosing, run one forced reconnect, one overlap test and one entity-heavy conversation. Those three cases usually reveal more about production suitability than another clean-file accuracy chart.

FAQ

What is the best real-time speech-to-text API for voice agents?

Deepgram is our first provider to test for a voice agent because Flux is specifically designed for conversational turn detection and interruption handling, while Nova-3 provides a strong general streaming path. AssemblyAI is the strongest alternative when you want configurable latency modes and turn controls. The final choice should be based on your own p95 latency, endpointing, and transcript-stability tests.

What is the cheapest streaming speech-to-text API in this comparison?

AssemblyAI’s Universal-Streaming value tier has the lowest public base rate in this shortlist at $0.15 per hour. Speechmatics Real-time Standard is $0.24 per hour, and Deepgram Nova-3 Monolingual is about $0.288 per hour. Do not compare price without checking model capability, billing behaviour, add-ons and the cost of downstream work triggered by unstable partials.

How should I measure real-time STT latency?

Measure client-side from the audio you send to the transcript event you receive, then keep transcript latency separate from end-of-turn latency. Log p50 and p95, not one best-case figure. For voice agents, add the first usable partial, revision count, false commits, and the time from the actual speech end to the event that starts the LLM.

Why do interim speech-to-text results keep changing?

A streaming recogniser has incomplete context. As more audio arrives, it can revise earlier words, punctuation and entities. That is normal. The application should treat interim text as provisional unless the provider gives a final marker or a sufficiently reliable stability signal. The dangerous design is not the mutable partials themselves, but the downstream code that behaves as though every partial were final.