The State of Voice AI, Mid-2026: A Technical Review

Voice is among the most natural interfaces available, and among the most difficult to implement well. It is hands-free and eyes-free, it imposes no learning curve, and it serves people who cannot type as readily as those who cannot read. Even so, nearly every team that has shipped a voice product has heard the same set of complaints in return. The system interrupted the user mid-thought. It spoke over them. It carried on after being told to stop. It left a long silence in which the user could not tell whether it had heard them.

A voice product is several layers of technology stacked on one another, and every one of those complaints comes from a single layer, the one that decides who is speaking and when. That layer receives the least engineering attention and produces the most visible damage. How much engineering it needs depends entirely on the product being built. A billing assistant and a language tutor can run the same underlying language model and still need completely different machinery beneath it.

Several companies now build voice models, and they have taken visibly different routes. Microsoft rebuilt the turn-taking machinery and left the reasoning model interchangeable. OpenAI fused conversation and reasoning into one system. NVIDIA released open weights and kept a hardware requirement. Google added vision. Amazon competed on cost. None of these is a better version of the others. They are different bets, and each one suits a different class of product.

This review sets out what is available, the workloads each option handles well, and the failure modes each one introduces.

Part 1: The Products and Their Requirements

Voice AI is not one market. The applications below are genuinely different products that happen to share a microphone, and each one stresses a different part of the stack. The usual mistake is to optimize for the wrong one.

Customer support and the contact center

Billing inquiries, order status, appointment changes, first-line triage. This is the highest-volume category and the most commercially proven. The caller arrives with a specific problem and expects it to be solved.

Everything here depends on the system knowing things. Policies contain exceptions, accounts carry histories, and the right answer to “why was I charged twice” lives in a database rather than in a model’s weights. This use case therefore needs deep reasoning and, above all, tool calling, meaning the ability to query systems of record in the middle of a conversation. An agent that cannot look up an account cannot do the job. It can only tell the caller, in a well-spoken way, that it does not know.

What it prioritizes is task completion, reliability, and tool access over rich conversational overlap. The exceptions sit at the sensitive end, collections, healthcare, a distressed or disputing caller, where how the exchange feels starts to carry real weight, and those cases deserve to be treated as their own category rather than lumped in with a balance check.

IVR and call routing

The task here is to understand intent well enough to route the call, without a phone tree.

For straightforward routing, the reasoning requirement is modest, since this is intent classification; what dominates is latency and intent reliability. The latency demand is the highest of any category, because the caller has not yet invested in the conversation. There is no sunk cost and no reason to be patient, so a two-second pause reads as a broken system and the caller hangs up. Every other use case gets some grace. This one gets none.

Roleplay and skills training

Sales reps rehearsing objections, agents practicing difficult calls, medical students taking patient histories. The system plays a person rather than an assistant.

The teaching sits in two places, the pressure applied during the conversation and the assessment delivered after it. The system has to stay in character and react plausibly, which is a moderate reasoning demand, but it does not need to be right about anything in particular. An angry customer is allowed to be unreasonable. What the system has to be is uncomfortable in a realistic way. The interaction is usually in one language, and tool calling barely matters.

Language learning

A learner practicing spoken language. This looks like roleplay, and it is not.

In roleplay, the conversation is a container for the scenario. In language learning, the rhythm of the conversation is the thing being taught, and that changes the requirements completely. A learner hunting for a word pauses for three seconds, and a system that reads that pause as the end of a turn cuts the learner off at exactly the moment they were doing the hard part. A tutor who stays silent while a learner struggles gives no sign of understanding, and silence is not neutral. It is discouraging. Corrective feedback delivered after the learner finishes a paragraph lands in the wrong place. A good tutor cuts in at the moment of the error.

Frontier reasoning alone does not solve this. Intervention timing matters just as much, and it is the harder half: the ability to act while the learner is still speaking, which almost nothing has.

Companions, characters, and NPCs

Games, entertainment, accessibility, companionship. The conversation is not a means to an end. It is the product.

So the quality bar sits somewhere other than everywhere else. Nothing is measuring task completion. The measure is whether the exchange felt like talking to someone. The demands are moderate reasoning, very little tooling, and a total reliance on the small conversational signals (the acknowledgment, the interruption, the timing) that make an exchange feel alive rather than transactional.

Field and in-car assistants

Hands busy, eyes busy, environment noisy. Voice here is not a convenience. It is the only channel available. Accessibility belongs in this category too, wherever voice is the primary interface for someone who cannot use a screen.

The distinguishing demand is tool calling under bad acoustic conditions. The system has to control things, navigate, and look things up while a truck engine runs. Noise suppression and echo cancellation stop being nice-to-haves and become the difference between a product that works and one that does not.

Real-time translation

Two people who do not share a language. This case is structurally different from all of the above.

Every other use case can, in principle, wait for the speaker to finish a sentence. Translation cannot. Useful simultaneous translation means output has to begin before the input has finished. That is what the task is, by definition. It also needs the broadest language coverage of anything here, by construction.

Summary

Two things fall out of that table, and they shape everything that follows.

Reasoning depth and overlap pull against each other. A system that reasons carefully about a fee schedule and a system that can say “mm-hm” while the user is still speaking are, today, two different systems built two different ways. That tension explains most of what looks strange about the current market.

Tool calling quietly disqualifies more options than anything else. That one requirement removes a whole category of otherwise excellent models.

Part 2: Evaluation Criteria

The review judges each option on eight capabilities. Each one is defined below, along with the reason it earns a place.

Duplex class

Almost every voice agent built to date works the same way. The user’s audio streams in. A component watches the waveform and waits for the user to stop making sound. When silence crosses a threshold, that component decides the turn has ended, closes the audio, and hands it downstream. The thing making that call is a Voice Activity Detector. Basic VAD identifies speech boundaries primarily from acoustic activity and silence, without understanding whether the speaker has actually completed their thought. It knows the user went quiet. It does not know whether the user was finished.

Everything downstream is hostage to that first judgment, and the judgment is made by the least intelligent component in the system.

The four complaints now stop being a list and become a single bug. A pause to find a word gets read as the end of a turn, and the model answers half a question. An interruption arrives, but the system has already committed to a response it cannot drop gracefully. A “mm-hm” offered while the system is talking, which in human conversation is not an attempt to take the turn at all, cannot be represented, because the channel is a lock and the user has just grabbed it.

That last case is the deep problem. Half-duplex operation makes the audio channel a mutex, one party at a time. Human conversation does not work that way. Overlap is not an error condition. It carries information: the backchannel that signals comprehension, the collaborative completion, the timing of an interruption that conveys the strength of a disagreement. If speaking and listening are mutually exclusive states, none of that can be expressed. That is not a matter of doing it badly. It cannot be done at all.

Three architectures exist.

A cascade transcribes, reasons, and synthesizes in series. That is three models, and prosody dies the moment speech becomes text.

Native speech-to-speech is one model, audio in and audio out, with no text step. It is faster, and it keeps the paralinguistics. But it still waits for a turn boundary, and that boundary is still a VAD.

Full-duplex runs both streams at once through a single forward pass. Many times a second, with both streams live, the model decides whether to speak, stay quiet, or drop in a short acknowledgment.

Notice what moved in that last diagram. The gate is gone. Turn-taking stopped being a preprocessing step and became something the model learned, conditioned on prosody rather than on words. That matters, because pitch contour is one of the strongest places where turn-yield cues appear, alongside syntax, duration, intensity, and discourse completion, and in face-to-face settings gaze and gesture as well. The transcription step in the first two architectures throws the acoustic part of that signal away before anything downstream can use it.

The practical test is simple. Can the system say “mm-hm” while the user is talking? Only full-duplex can. A turn gate can be tuned, and even made semantic, as Azure’s is. What it cannot be made to do is participate in overlap.

Pluggable reasoning

Conversational models have to be small. A 7B model can run a duplex forward pass in real time. A frontier model cannot. So the intelligence has to come from somewhere else, and the question is whether that somewhere is a slot the buyer controls.

There are three answers on the market. Welded, where the vendor chose and the buyer lives with the choice. Hand-rollable, where the buyer can function-call out to another model and inject the result back. Pluggable, where the reasoner is a configuration parameter.

This decides whether the system can be made smart enough for a given domain, and whether the buyer is locked to one vendor’s model roadmap.

Tool calling

Whether the system can query the buyer’s systems of record in the middle of a conversation. For anything transactional, this is the whole product.

Languages

How many, and how well. This is where technically excellent options die in procurement, and where marketing is loosest. A system can support a language and still speak it with a foreign accent and phrasing no native speaker would use. For a deployment in India or the Gulf, this filter belongs first rather than last.

Availability

Managed API, self-hosted model, or consumer feature. Whether there is an SLA, whether it sits in a cloud provider’s catalogue, whether it needs GPUs, and who carries the pager at three in the morning. This is the criterion that produces the strangest finding in the whole review.

Integration burden

Whether the buyer gets a managed API with SDKs and telephony, or a WebSocket to terminate, sessions to manage, and GPUs to scale. The gap between “the model works” and “the product is live” is where voice projects die: telephony, session resumption, noise suppression, observability. Whether these come in the box moves a timeline by quarters.

Cost shape

Not the per-minute number, but the shape of it. A per-minute API bills linearly forever. A self-hosted model has a high fixed cost, no per-conversation model fee, and low incremental cost while it runs within provisioned capacity. Which one wins depends on volume, and the crossover point is not where most buyers assume.

Observability

Whether the buyer can see what happened, and whether the transcripts are clean enough to audit. In banking, healthcare, and telecom, this gates everything else. It is also where one of the most exciting models has a flaw that almost nobody mentions.

Worth being precise about what the baseline is, because most of these ship the same thing and it is easy to wave it off as “standard.” The baseline is the vendor’s own request and response logs, usage records, and latency metrics, viewed through their cloud console: CloudWatch for Bedrock, Cloud Logging and Cloud Monitoring for Vertex, the session dashboard for OpenAI. That captures the transcript of each turn and the bill at the end of the month, which is enough to audit a conversation and track spend. What it does not capture, unless the team wires it up, is voice-specific instrumentation: how often the agent was interrupted, how many turns a call ran, how long the first token took to arrive. Those are the numbers that tell a voice team whether the product actually feels good, and Azure is the one option that emits them out of the box through OpenTelemetry. So in the table below, a named cloud logging service means “you can reconstruct and audit the call,” not “you can see how the conversation felt.”

Part 3: The Options

Azure Voice Live

Voice Live is not a model. It is a session broker, an orchestration layer sitting on a WebSocket that handles speech recognition, synthesis, turn detection, interruption, noise suppression, echo cancellation, and avatars, all in one place. It is generally available on Foundry.¹⁰

The architectural decision that matters is that the reasoning model is a query parameter.

wss://<resource>.services.ai.azure.com/voice-live/realtime
     ?api-version=2026-04-10&model=gpt-realtime

The endpoint is identical for every model. Changing model= changes the brain. Point it at gpt-realtime and the result is a native audio model. Point it at gpt-4.1 and the system has quietly become a transcribe-reason-synthesize cascade. Point it at a deployment in the buyer’s own Foundry resource and it is self-hosted. The client code does not change, because the broker absorbs the difference.

What this buys is that conversational quality becomes a property of the transport rather than of the model. Everything conversational lives permanently in the broker, whatever is placed behind it. There is a semantic VAD that uses a speech model rather than an energy threshold to decide turn boundaries, and that holds up in noise. There is end-of-utterance detection built specifically so that a thinking pause does not get read as the end of a turn, and Microsoft’s documentation is careful to say it does this without adding perceivable latency. There is smart end-of-turn detection working on the raw audio stream. There is auto-truncation, so that an interruption kills the response cleanly. And there are proactive messages, so that the agent can speak first.¹⁰

That list maps one-to-one onto the four complaints. It is not a coincidence.

The consequence is that a text-only model, one that cannot hear audio at all, still inherits every bit of it. Microsoft attacked the turn-taking problem from the half-duplex side, seriously, with purpose-built models rather than tuned thresholds, and in exchange kept the ability to plug any reasoner in behind it. The system is also event-compatible with the Azure OpenAI Realtime API, so migrating an existing Realtime app costs almost nothing.¹¹

Where it fits. The strongest option available for customer support: deep reasoning through bring-your-own-model, MCP tool calling, Foundry Agent Service integration, and OpenTelemetry instrumentation that covers first-token latency, turn count, and interruption count.¹⁰ Good for field and in-car, where the noise suppression and echo cancellation are already in the box. Good for roleplay training, and Microsoft’s own Live Voice Practice accelerator is exactly this, with contact-center agents rehearsing hard calls while Azure OpenAI scores the transcript against a rubric. Good for IVR, where the semantic VAD goes straight at the premature-cutoff problem.

Considerations. It is still half-duplex. Microsoft’s Build materials describe the WebSocket and WebRTC interfaces as bidirectional and full-duplex, and that language is doing careful work. It is a claim about the pipe, not about the model. The system can detect that the user interrupted and stop talking. It cannot say “mm-hm” while the user speaks. Regional mismatch is the latency trap. If the model deployment sits in a different region from the Voice Live resource, every turn becomes a cross-region round trip. And pluggability costs latency, which is not the broker’s fault. The broker hop is tens of milliseconds. Choosing a text reasoner instead of a native audio one puts a three-stage cascade behind it, and that is hundreds. Pluggability is expensive. The plug is not. Pricing is tiered, and the buyer does not pick the tier. The chosen model determines it.¹⁹

NVIDIA PersonaPlex 7B

A 7B full-duplex speech-to-speech model, released in January, built on Kyutai’s Moshi architecture with Helium as the language backbone.⁶ It encodes incoming audio with a neural codec, the Mimi codec running at 24 kHz, and predicts text and audio tokens autoregressively through a pair of transformers, one over time and one over the codec depth.⁹ An inner-monologue stream predicts one text token per 80 ms audio frame, which is how the model keeps a running sense of what is being said without stopping to transcribe. The incoming user audio is fed to the model while it generates its own outgoing speech, so listening and speaking happen at once.

The problem it solves is the one that kept Moshi a demo. Moshi cracked full-duplex but shipped with a single voice and a single personality. PersonaPlex adds a hybrid system prompt: a short audio sample that sets the voice, plus a text prompt that sets the role and background. It holds that persona through interruptions, backchannels, and mid-sentence barge-ins. To test it, NVIDIA extended FullDuplexBench with a new benchmark built around customer-service roles.⁸

On conversational dynamics, response and interruption latency, and task adherence, it outperforms the other open and commercial systems NVIDIA compared it against. The released checkpoint backchannels noticeably more, and handles pauses better, than the setup described in the paper.

The license is genuinely permissive. The weights fall under NVIDIA’s open model license, the code under MIT, and the model card states that the model is ready for commercial use.⁷ There is no per-minute bill, which at volume matters more than it first sounds. There is no per-conversation model fee, and incremental cost can be very low while the workload stays within provisioned GPU capacity, whereas a managed API bills for every minute. The caveat is that GPU energy, capacity reservation, bandwidth, and the step change when concurrency outgrows the fleet are all real costs the buyer now owns.

The strategy behind giving it away is not subtle. It needs A100- or H100-class silicon to run in real time. The software is free. The hardware is paid.

Where it fits. Best in class for companions and characters, which is what the persona conditioning was built for. It is the only option that can backchannel while a language learner struggles through a sentence. It is workable for roleplay training where English-only operation and the absence of tools are acceptable.

Considerations. The limitations here are severe. It is English-only, and the model card is explicit about it, which for India or the Gulf ends the conversation. It has no tool calling. NVIDIA’s own stated next steps are post-training alignment and tool integration, which is to say it does not have them yet, and an agent that cannot look up an account cannot do the job. At 7B parameters it wins on how it talks, not on what it knows, and it will not reason about a fee schedule. Its transcripts come out broken. Because it streams audio in real-time frames at 24 kHz, text tokens sometimes land across frame boundaries and split in the middle of a word. That is fine when the audio is the output, and a problem in a regulated industry that needs clean logs for audit, which banking and telecom do. And there is no managed endpoint anywhere. Not on Azure, not in NVIDIA’s own inference catalogue, nowhere. It is a gated checkpoint on HuggingFace and a repository on GitHub that ships a Python server and a web UI. The buyer runs the GPUs, terminates the WebSockets, manages the sessions, builds the observability, and carries the pager.

OpenAI GPT-Live-1

Launched on 8 July, and now the default behind ChatGPT Voice. It is full-duplex, so it can listen and speak at the same time, show that it is paying attention with a short cue, engage in quick back-and-forth, or stay quiet while the user thinks.

For anything that needs real thinking or a web search, it delegates to a frontier model running in the background, and keeps talking to the user while that runs.¹

That delegation only works because of full-duplex operation. The small conversational model can hold the floor without blocking the input stream. In a half-duplex system, that same gap is dead air, or a spinner. The two innovations are not independent. The orchestration rests on the architecture.

The benchmark numbers need reading with some care. GPT-Live scores far above the old voice mode on GPQA, which tests expert scientific reasoning, and on BrowseComp, which tests agentic web search. But GPT-Live is not doing that reasoning. It is delegating it, so the GPQA figure is really the frontier model’s score arriving through a voice pipe. And the BrowseComp comparison is against a predecessor that had no agentic search at all, so it measures a capability arriving rather than improving.

The number that holds up is the human one. In matched five-to-ten-minute conversations judged on turn-taking, interruptions, flow, and how natural the exchange felt, evaluators strongly preferred it over the old voice mode.¹ That is the number that matters for anything conversational, and it is good.

Where it fits. As a product, it is the best conversational experience on the market, and for anyone who wants to understand what full-duplex feels like before committing to anything, half an hour with ChatGPT Voice is the cheapest research available. As something to build on, it is not available yet.

Considerations. It is a ChatGPT feature. OpenAI’s entire commitment to developers is one sentence saying they plan to bring the models to the API soon, plus a form to fill in for notification. There is no endpoint, no model ID, no pricing, and no date. The reasoner is welded shut. The Instant, Medium, and High settings choose how hard it thinks, not what does the thinking. And OpenAI’s safety argument depends on that welding. The system card says that when the models delegate, the resulting work reflects the safety training of the underlying model doing the work.² That argument dissolves the moment the delegate becomes pluggable, so there is a structural reason not to expect the slot to open. Non-English quality is uneven. OpenAI says the model is optimized for the most popular languages in ChatGPT, and that for certain languages it may have a non-native accent or gaps in fluency. One more point, for anyone building companions. The system card shows a slight regression on emotional reliance against the previous voice mode, which OpenAI notes is not statistically significant.² The direction is the point. Making a voice more pleasant to be around and guarding against people leaning on it too heavily pull in opposite directions. If conversational quality is the product, that tension is part of the product too, and it is better to design for it deliberately than to discover it later.

Google Gemini Live

Native speech-to-speech, generally available on Vertex with production SLAs, on a Gemini native-audio model that takes continuous streams of audio, video, or text.¹² It operates on the raw audio rather than a transcript, so acoustic features such as pitch, pace, and tone reach the model instead of being discarded at a transcription step. It supports barge-in, function calling, code execution, and Google Search as a tool.

Two properties separate it from the rest. Its native-audio coverage is broad: thirty voices across twenty-four languages, with the model switching languages mid-conversation without pre-configuration, which for a multi-region product removes a whole class of routing logic.¹³ And it accepts video input, so a camera feed can be streamed alongside the audio and the model can answer questions about what it is looking at. No other production system does that, which leaves it as the only option for augmented reality, or for accessibility cases where the user needs to ask about what is in front of them.

Where it fits. Multilingual customer support. Field assistants with a camera. High-volume work where cost dominates.¹⁴

Considerations. It is half-duplex, and its speaker-switch latency is the slowest of the managed options at roughly 1.3 seconds,⁶ which is the whole distance to full-duplex. Telephony needs the buyer’s own bridge, with no first-party SIP. Session resumption, done with ephemeral tokens and context handoff, is real engineering work rather than a checkbox. Observability is the standard Google Cloud picture: request and response logging through Cloud Logging and latency metrics through Cloud Monitoring, which capture the transcript and the bill but not turn-level voice instrumentation unless the team builds it.

OpenAI GPT-Realtime 2.1

This is the developer surface OpenAI actually ships, and it is not GPT-Live. Two models were released on 6 July, two days before GPT-Live was announced, which indicates that the two stacks are meant to coexist rather than replace each other.³

It is fast half-duplex. The interruption recovery is excellent, and the mechanism is worth knowing: on WebRTC and SIP connections the server buffers the output audio, so it knows exactly how much has actually played, and on a barge-in it truncates the unplayed remainder cleanly rather than talking over the user or losing its place.⁴ The model still does not speak while it listens, and it will not backchannel while the user talks.

The July release improved alphanumeric recognition, silence and noise handling, and interruption behavior, and cut p95 latency by at least 25 percent.³ Alphanumeric recognition sounds like a small thing until the system is taking account numbers or order references over a phone line, at which point it is the whole game. The release also added two voices.³

It has first-party SIP, which none of the others do,³ and that is a real advantage for telephony: the API connects directly to the public phone network, PBX systems, and desk phones, with no third-party bridge to run and pay for. It also has remote MCP servers, image input, and parallel tool calls, so it can pull in external tools, ground a conversation in a screenshot, and fire several lookups at once. Prompt caching cuts audio input cost substantially on long sessions.

The under-appreciated point here is that the buyer can build GPT-Live’s delegation pattern themselves. Function-call out to a frontier model, and inject the result back into the session. It is not secret sauce. What is lost is the ability to keep talking while it runs, so the conversation stalls where GPT-Live’s would not. But the buyer gets to choose the reasoner, which GPT-Live does not allow.

Considerations. Premium pricing next to Gemini and Nova,⁵ and token costs that are unpredictable without caching discipline. Observability is what the OpenAI platform gives you: session logs and usage events in the dashboard, enough to reconstruct a conversation and audit spend, but without the turn-count and interruption-count instrumentation that a voice deployment eventually wants and that Azure ships in the box.

Amazon Nova 2 Sonic

Native speech-to-speech on Bedrock, and a single unified model rather than a stitched pipeline. Speech understanding and speech generation live in one model, so there is no separate transcription or synthesis service to run, and audio goes in and audio comes out end to end, typically in under half a second. AWS exposes it through a bidirectional streaming API, InvokeModelWithBidirectionalStream, an event-driven connection over HTTP/2 that keeps a persistent socket open and lets audio flow in both directions at once, with frames arriving on the order of every 32 milliseconds.¹⁵

It has the cheapest flat per-minute rate of the managed options, roughly an order of magnitude below OpenAI Realtime.¹⁸⁵ Architecturally it is a hybrid design with a dedicated speech encoder that extracts prosody, pitch, and non-verbal features from the input audio at the encoder stage, ahead of the language model, so those features are available to the model rather than flattened into text first.

The rest of the surface covers the transactional path. Turn detection is native, with adjustable sensitivity for how quickly it treats a turn as ended, and barge-in is handled. Function calling runs during a live conversation, emitting tool-use events with names and arguments and reading the results back in, and it connects to Bedrock Knowledge Bases for retrieval, so document grounding is a first-party path rather than a separate build.¹⁶ Voice, temperature, and top-p are configuration parameters. Because it runs inside Bedrock, access, network isolation, and logging go through the same IAM, VPC, and CloudWatch primitives as the rest of an AWS deployment.

Where it fits. Cost-dominated support workloads on AWS, in supported languages, where tool calling and retrieval are needed but a camera and wide language coverage are not.

Considerations. Five languages, English, Spanish, German, French, and Italian,¹⁷ and for a product that needs Hindi, Arabic, or Mandarin that is the whole story. It is audio only, with no native vision: adding sight means bolting on a separate agent layer to feed it frames, which is exactly the work Gemini Live does not need. It reasons at the level its size allows, so a genuinely hard, multi-step case still wants a stronger model behind a tool call rather than the base model alone. Observability is the standard AWS picture: model-invocation logs and metrics through CloudWatch, enough to audit a conversation and watch the bill, without the turn-level and interruption-level voice instrumentation Azure ships by default.

Part 4: Three Things Outside the Model Comparison

The orchestration layer. Most teams do not integrate a model directly. They deploy through Vapi, Retell, LiveKit, or Pipecat, which handle telephony, agent logic, monitoring, and scaling. These sit on top of whichever model is chosen, and their costs stack on top of model costs. That is a large part of why the per-minute prices quoted bear so little resemblance to what anyone actually pays. For a buyer rather than a builder, that layer may be the first decision and the model the second.

The cascade is not dead. Most production voice systems in 2026 are still transcribe-reason-synthesize pipelines, and the reason is not inertia. Every stage produces a trace, so when a conversation goes wrong the point of failure can be found, and thousands of conversations can be graded at scale. Speech-to-speech gives a transcript and a shrug. In a regulated domain where auditability outranks naturalness, a well-built cascade behind good turn detection is a legitimate answer rather than a legacy one. Voice Live with a text model in the slot is exactly that, managed.

Evaluation is not optional. Voice agents are probabilistic. The same scenario passes on one run and fails on the next, which means a fixed set of test cases will not tell the team much. A simulation harness covering accents, interruptions, and background noise should be budgeted as part of the build, not after it.

Part 5: The Pattern Behind the Options

Put the six side by side, and something becomes visible that no single product page mentions.

Every managed API here supports bidirectional streaming and interruption handling, but they differ in whether the model merely detects incoming speech or can participate meaningfully during overlap. GPT-Live and PersonaPlex clearly demonstrate learned backchanneling and continuous conversational behaviour; the other systems primarily expose barge-in, streaming perception, and turn-based response generation. And the two that participate during overlap are a checkpoint the buyer runs on their own A100s and a feature inside a consumer app, not a managed API you can call. That is not a coincidence of release timing. It is a consequence of how the two capabilities interact.

Full-duplex operation means the model handles its own turn-taking, inside its forward pass, as part of what it learned. Which means turn-taking is no longer something that can be pulled out and put in a broker. Which means the model is no longer replaceable, because everything conversational lives inside it now. Pluggability needs the conversational layer and the thinking layer to come apart. Full-duplex needs them fused.

Nobody has both, and this is not a roadmap gap that somebody closes next quarter. A buyer waiting for a managed full-duplex API with a reasoner of their choosing behind it may be waiting on something that needs a new architecture rather than a new release.

The other thing worth watching is where the value settles. Full-duplex will be ordinary within a year, since Google, NVIDIA, and others are all pushing the same architecture and the technique is published. What will not commoditize is the delegation surface, the layer that decides which model gets the traffic, because whoever holds the socket holds the routing. That is a reasonable explanation for why the reasoner slot is closed almost everywhere. Microsoft is the exception, and it is the most interesting decision in the review.

Part 6: The Options Side by Side

Two Things People Conflate

Before the recommendations, two distinctions that decide whether the comparison above is read correctly.

Full-duplex does not mean low latency. Low latency is a consequence of full-duplex, not the point of it. The point is overlap, meaning the ability to act while the other party is still speaking. A language tutor can take 400 milliseconds to answer, and what it cannot do is stay silent while a learner flounders. An IVR needs to answer in 200 milliseconds, because the caller has not committed yet, and it never needs to interrupt anyone. Same word, opposite requirements. The question to ask is which property is needed, not which number is smaller.

The headline per-minute price is not the cost. Real deployments carry the orchestration layer, the telephony, and the reasoner on top of the model rate. And note the inversion that creates. A GPU serving concurrent PersonaPlex streams carries no per-conversation model fee, and incremental cost stays low while it runs within provisioned capacity, whereas a per-minute API bills for every minute. At sufficient volume, absorbing the operational burden can be the cheaper choice rather than the expensive one, as long as the buyer accounts honestly for the energy, capacity, and labour that come with it.

Part 7: Recommendations

Customer support, IVR, field assistants, roleplay training. Azure Voice Live. It goes straight at the failure modes users complain about, with semantic VAD and end-of-utterance detection for the cutoff problem and auto-truncation for the interruption problem, and it allows the buyer to bring the reasoning model the domain needs. It is the only managed option where choosing the brain is a single line of configuration.

Companions, characters, language fluency, where the conversation is the product and English is acceptable. PersonaPlex. The full-duplex advantage is real, the license permits commercial use, there is no per-conversation model fee and incremental cost stays low within provisioned capacity, and nobody will sell an equivalent. The operational layer has to be built in-house.

Broad language coverage, a camera, or lowest managed cost. Gemini Live, accepting the turn-handoff gap and building a telephony bridge in-house.

Telephony plus recognition accuracy. GPT-Realtime 2.1, hand-rolling the delegation to whichever reasoner is preferred.

Regulated, audit-heavy work. A cascade behind strong turn detection, for the per-stage traces. Voice Live with a text model in the slot is a managed version of exactly that.

If the plan was to wait for GPT-Live’s API. Do not build a timeline on it. The public commitment is one sentence and a signup form, and OpenAI shipped a Realtime update two days before announcing GPT-Live, which suggests the two stacks are meant to coexist rather than one replacing the other.

Sources

Superscript numbers in the text link to the matching entry below. Product capabilities, benchmarks, and pricing are drawn from primary vendor documentation and the cited papers, current as of mid-2026.

1. OpenAI. Introducing GPT-Live. 8 July 2026 — full-duplex behaviour, asynchronous delegation to a frontier model, and the human preference evaluation. openai.com/index/introducing-gpt-live
2. OpenAI. GPT-Live System Card — the welded reasoner, the delegate-safety argument, the emotional-reliance measure, and the non-English caveat. deploymentsafety.openai.com/gpt-live
3. OpenAI. Introducing gpt-realtime and Realtime API updates for production voice agents — first-party SIP, remote MCP, image input, new voices, and the p95 latency reduction. openai.com/index/introducing-gpt-realtime
4. OpenAI. Realtime API guide — VAD-driven interruption, server-side truncation of unplayed audio, and prompt caching. platform.openai.com/docs/guides/realtime
5. OpenAI. API pricing — Realtime audio input and output token rates. openai.com/api/pricing
6. NVIDIA ADLR. PersonaPlex: Natural Conversational AI With Any Role and Voice. 15 January 2026 — Moshi and Helium foundations, persona conditioning, the customer-service benchmark, and the response and interruption latency comparison (about 0.07 s versus roughly 1.3 s for Gemini Live). research.nvidia.com/labs/adlr/personaplex
7. NVIDIA. PersonaPlex code and model card (GitHub, Hugging Face) — open model license, MIT code, ready-for-commercial-use statement, and the 24 kHz streaming detail. github.com/NVIDIA/personaplex · huggingface.co/nvidia/personaplex-7b-v1
8. Lin et al. Full-Duplex-Bench: A Benchmark to Evaluate Full-Duplex Spoken Dialogue Models on Turn-taking Capabilities. arXiv:2503.04721 — the pause-handling, backchannel, turn-taking, and interruption metrics NVIDIA extended for its service benchmark. arXiv:2503.04721
9. Roy, R., et al. PersonaPlex: Voice and Role Control for Full-Duplex Conversational Speech Models. arXiv preprint, 2026.
10. Microsoft. How to use the Voice Live API (Azure AI Foundry) — the session broker, Azure semantic VAD, semantic end-of-utterance detection, noise suppression, echo cancellation, and OpenTelemetry tracing for first-token latency, turn count, and interruption count. learn.microsoft.com/azure/ai-services/speech-service/voice-live-how-to
11. Microsoft. Voice Live API reference — the model= parameter and event compatibility with the Azure OpenAI Realtime API. learn.microsoft.com/azure/ai-services/speech-service/voice-live-api-reference
12. Google Cloud. Gemini Live API available on Vertex AI — native-audio model, continuous audio, video, and text input, barge-in, and tool use. cloud.google.com/blog/products/ai-machine-learning/gemini-live-api-available-on-vertex-ai
13. Google Cloud. Gemini Live API: configure language and voice — thirty native-audio voices across twenty-four languages, with mid-conversation language switching. docs.cloud.google.com/…/live-api/configure-language-voice
14. Google Cloud. Generative AI on Vertex AI pricing — Gemini Live audio token rates. cloud.google.com/vertex-ai/generative-ai/pricing
15. AWS. Introducing Amazon Nova Sonic. — unified speech-to-speech model, the InvokeModelWithBidirectionalStream event-driven streaming API, native turn detection, function calling, and sub-500 ms latency. aws.amazon.com/blogs/aws/introducing-amazon-nova-sonic
16. AWS. Amazon Nova 2 Sonic AI Service Card — model overview, encoder design, and intended-use notes. docs.aws.amazon.com/ai/responsible-ai/nova-2-sonic/overview
17. AWS. Amazon Nova Sonic language support — the five supported languages: English (US and UK), Spanish, German, French, and Italian. docs.aws.amazon.com/nova/latest/nova2-userguide/sonic-language-support
18. AWS. Amazon Bedrock pricing — Nova Sonic per-minute audio rates. aws.amazon.com/bedrock/pricing
19. Microsoft. Azure AI Voice Live API: what’s new and the pricing announcement — general availability and the model-tiered pricing structure. techcommunity.microsoft.com/…/4428687