What full-duplex voice leaves you to build

A voice demo is the most persuasive thing in AI right now, and the most misleading. You call the number, you cut in halfway through a sentence, the agent stops instantly and picks up your correction as though it had been waiting for it. Nothing about it resembles the phone tree you were dreading. Ten minutes later you are sketching an agent that answers your line, books the job and takes a deposit.

The demo is honest about the thing it is showing. Turn-taking was the hard problem, and it now sits inside the model at both large providers [1][6]. What the demo hides is everything that was standing behind that problem: what the agent says while your booking system thinks, what a minute of conversation costs when the caller rambles, what happens at minute 11 of a 20-minute call, and what you are required to tell the person on the other end before any of it starts. This guide is for a solo operator or small team about to put a voice agent in front of real callers, or paying someone to. It is not for anyone comparing enterprise contact-centre platforms, and it assumes you or a contractor can call an API.

Full duplex is the model’s job now, and it is close to done

The word is borrowed from telecoms. Half duplex means one party transmits at a time, like a walkie-talkie. Full duplex means both transmit at once, like a phone call. Applied to a voice model it means the model does not wait for silence before it starts working, and it can be cut off mid-word without losing its place.

OpenAI describes the speech-to-speech path as the one where “the model handles live audio input and output directly”, and lists “barge-in, low first-audio latency, natural turn taking, and realtime tool use” as what you get for choosing it [1]. On WebRTC and SIP connections, “the server will automatically truncate unplayed audio when there’s a user interruption” [2]. Turn detection is a setting rather than something you build: you configure it through turn_detection, disable it entirely by setting it to null, or keep detection running while suppressing automatic replies by setting turn_detection.interrupt_response and turn_detection.create_response to false [2].

That is the part you no longer have to engineer. Treat it as a floor, not a feature. Nobody will thank you for an agent that handles interruptions, in the same way nobody thanks a phone for having a dial tone. The work that decides whether your agent is usable is all downstream of it.

The stall moved out of the model and into your backend

Here is the durable version of what changed. When the model paused to think, silence was the model’s fault and there was nothing you could do about it. Now the model does not pause, so any silence on the line is your backend taking its time, and filling that gap is a scripting decision you own.

The current guidance is narrower than most people assume. OpenAI tells you to “use short preambles only when they help the user understand that work is happening”, to “describe the action, not the internal reasoning”, and to keep it “natural, calm, and concise” [3]. The example patterns are flat and specific: “I’ll check that order now.” and “I’ll look up your appointment details.” [3]. The anti-patterns are the ones every builder reaches for first, filler on the order of “Let me think…” or “One moment while I process that…” [3].

The other detail worth copying is the ordering, which the guide states as a sequence rather than a suggestion: “Before any tool call, say one short line like ‘I’m checking that now.’ Then call the tool immediately” [3]. The line goes out first and the tool call follows without waiting, so the caller hears something while the query runs instead of after it returns. Two more instructions from the same guide are worth pinning to your system prompt. Tell the model to “deliver your audio response fast, but do not sound rushed”, which buys perceived responsiveness without wrecking comprehension [3]. And tell it not to reason through bad audio: the guidance is blunt, “Do not reason when the audio is unclear”, ask instead [3]. A voice agent that guesses at a half-heard postcode creates a worse problem than one that asks twice.

Speech-to-speech or a chained pipeline, decided on one question

There are two architectures and the choice is not close once you know what you are optimising. Speech-to-speech is “best for natural, low-latency conversations” [1]. A chained pipeline, where audio becomes text, text goes to a normal model, and the reply is spoken back, is “best for predictable workflows or extending an existing text agent” and gives you “stronger control over intermediate text, existing text-agent reuse, or a simpler extension path” [1].

The question that decides it is whether the exact words matter after the call ends. If the transcript is the product, because you are taking an order, capturing consent, or handing a record to someone who will be held to it, the intermediate text is not a detail and you want the chained pipeline where you can see and validate it. If the call is the product, because the caller will judge you on whether it felt like talking to a person, take the latency and go speech-to-speech.

If your line does both jobs, the honest split is the chained pipeline for the parts that touch money and speech-to-speech for the parts that touch mood. Building both is a real answer and a more expensive one. If you can only build one this quarter, build the one that matches the flow that fails most embarrassingly today.

Price a minute before you design a single flow

Voice is billed in two shapes and the shape changes how you budget. OpenAI prices gpt-realtime-2.1 per million tokens: $32.00 for audio input, $0.40 for cached audio input, $64.00 for audio output, $4.00 for text input and $24.00 for text output [4]. The smaller gpt-realtime-2.1-mini runs $10.00 audio input, $0.30 cached audio input, $20.00 audio output, $0.60 text input and $2.40 text output [4]. Two adjacent models are priced by the minute instead: gpt-live-transcribe at $0.017 per minute and gpt-realtime-translate at $0.034 per minute [4].

Google publishes both units for the same model, which makes the arithmetic easier to reason about. On gemini-3.1-flash-live-preview, described as a “low-latency, audio-to-audio model optimized for real-time dialogue”, audio input is “$3.00 or $0.005/min (audio)” per million tokens, text input is “$0.75”, and audio output is “$12.00 or $0.018/min (audio)” [6].

The practical consequence of token-shaped pricing is that a caller who rambles costs more than a caller who does not, and you cannot tell which you have until the call is over. Per-minute figures are the ones to plan with, because a minute is the unit your business already understands. Take the ceiling case, where the model both listens and speaks for every second of the call, and Google’s numbers put a minute at about 2.3 cents of model cost [6]. That is the model only. Telephony, transcription storage and whatever your own backend costs sit on top.

Sessions end before your calls do

This is the limit that catches people who tested with two-minute demos. On Google’s Live API, “without compression, audio-only sessions are limited to 15 minutes, and audio-video sessions are limited to 2 minutes” [5]. Separately from the session, “the lifetime of a connection is limited as well, to around 10 minutes” [5]. A support call that runs 20 minutes is not one session and one connection. It is a session you extended and a connection you rebuilt, at least once, while someone was talking.

The tools for surviving that are documented and unglamorous. Context window compression, configured through the contextWindowCompression field with a sliding window and a token threshold, is what lets a session run past its default limit [5]. Session resumption is what carries you across a dropped connection: the server issues SessionResumptionUpdate messages containing handles you reconnect with, and “resumption tokens are valid for 2 hr after the last sessions termination” [5]. You also get warning before the door closes, because “the server sends a GoAway message that signals that the current connection will soon be terminated”, including a timeLeft value [5].

Build the reconnect before you build the second feature. The failure it prevents is the worst one a voice agent has, which is the agent that forgets what the caller said 90 seconds ago and asks for the booking reference again. A slow agent is survivable. An agent that has lost the last two minutes is not.

You have to say it is a machine, and calling people is its own problem

Two rules sit outside your product decisions. In the EU, providers must ensure that AI systems “intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system” [7]. The exception is narrow, covering only cases where it is obvious to a person “who is reasonably well-informed, observant and circumspect” in context [7]. A convincing voice agent is the definition of not obvious. Article 50 also requires that providers generating synthetic audio “ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated” [7]. These obligations have applied since 2 August 2026 under Article 113 [7]. The text writes them onto providers, so if you are commissioning the agent rather than building it, settle in the contract who is carrying them.

In the United States the harder rule is about who starts the call. The FCC ruled on 8 February 2024 that calls made with AI-generated voices are “artificial” under the Telephone Consumer Protection Act, in a ruling that “takes effect immediately” [8]. The FCC’s own framing of the consequence is the part to read twice: under its rules, telemarketers must “obtain prior express written consent from consumers before robocalling them”, and the ruling “ensures AI-generated voices in calls are also held to those same standards” [8]. Answering your own inbound line is a different legal posture from dialling a list. If your plan involves outbound calls to people who have not given you written consent, the plan is the problem, and no model choice fixes it.

Disclosure is also the cheapest thing on this list to build. Say it in the first sentence, plainly, and move on. A caller who would have hung up on a machine is going to work out what it is anyway, later in the call, in a worse mood.

What still goes wrong

The interruption handling that looks automatic is only automatic on some transports. Over a WebSocket connection you have to do it yourself, watching for input_audio_buffer.speech_started, stopping playback immediately, and sending a conversation.item.truncate event that removes the unplayed portion of the model’s last response [2]. Skip that and you get the strangest bug in voice work: the model believes it said a sentence the caller never heard, and the rest of the call proceeds on a shared history that was never shared. It presents as an agent that is subtly, unfixably confused, and it will not reproduce in your text-based tests.

Cost stays hard to forecast. Audio priced per token means your bill tracks how much people talk. Plan on the assumption that the longest calls are the messiest ones, which are also the ones the agent is least likely to resolve on its own. Watch the first month’s real distribution rather than an average, and set a hard spending cap before you point a phone number at anything.

The rest is the ordinary limit of the category. A voice agent has no way to see that the caller is furious except through words, it will not know that your busiest supplier changed their return policy last week unless you told it, and a handoff to a human is still the feature that decides whether callers trust the whole arrangement. None of that is solved by a better model, and none of it is what the demo was demonstrating.