Comparing turn-taking in GPT-Live-1 and gpt-realtime-2.1
I ran OpenAI’s full-duplex GPT-Live-1 through the same turn-taking tests as gpt-realtime-2.1 and recorded both. GPT-Live talked through “yeah” and “mm-hmm”, took about 1.4 s to stop when interrupted, and often answered before the caller finished the sentence.
Contents
In my last post I measured how gpt-realtime-2.1 decides you’ve finished talking. Its turn detection is a separate step (VAD, voice activity detection) that you configure, and every setting had a tradeoff: cut the caller off, or make them wait.
GPT-Live-1 works differently. It’s full duplex, so it listens while it talks, and there’s no turn-detection setting to pick. I ran it on the same 12 sentences, 2 synthetic voices and 7 caller clips, for about $2.40.
- It kept talking through 19 of 20 backchannels (“yeah”, “mm-hmm”, “okay”, “right, right”). gpt-realtime, with my client cutting playback on caller speech, stopped on all 32.
- When the caller actually interrupted, it stopped in 14 of 15 trials, but took a median 1.41 s to do it.
- It spoke during 54 of 117 mid-sentence pauses. Sometimes that was just “Mm-hmm”; often it was a guess at the answer.
- Its replies were quick: median 1.30 s after the caller finished, 3.5 s at worst.
“Wait, stop” takes about 1.4 seconds
Backchannels are the good news. A caller saying “yeah” halfway through instructions wants you to keep going, and GPT-Live did in 19 of 20 trials. The one exception was an “okay”, which is in the clips at the bottom.
The cost shows up when the caller really wants the floor. It stopped for 14 of 15 interruptions, with a median of 1.41 s and a range of 0.66 to 2.12 s. That’s a long time to keep talking after someone says “stop”.
This isn’t quite a fair fight. gpt-realtime’s 0.1 s comes from my client: it cuts playback as soon as the server reports caller speech, which is also why it stops for every “yeah”. GPT-Live sends no such event, so there’s nothing on the client side to tune.
It talks during pauses, and sometimes answers early
In this test the caller says half a sentence, pauses for 0.3 to 2.5 s, then finishes. GPT-Live spoke before the caller finished in 54 of 117 trials. In 12 of those it only said something like “Mm-hmm” or “Got it”. The rest were real replies.
I didn’t expect it to answer unfinished questions. It replied early in 12 of 58 unfinished-clause trials, not far from server VAD (17 of 56), while semantic VAD almost never did (1 or 2). Dictation was the worst case: it spoke in 18 of 29 trials, often reading back half a phone number or gate code.
Longer pauses made it more likely: 1 of 22 trials at 0.3 s, 8 of 23 at 0.6 s, and 17 and 16 of 24 at 1.5 s and 2.5 s.
Its replies never took long
The upside of being eager is that nobody waits. GPT-Live’s median reply gap was 1.30 s, its 90th percentile 1.83 s, and its slowest 3.5 s, about the same as server VAD. Semantic VAD on low had a 90th percentile of 8.7 s. In 2 of 117 trials GPT-Live didn’t reply at all.
It also didn’t get stuck on fragments. When the caller split “what the capital of… Australia is?”, semantic VAD on low waited about 9 s. GPT-Live answered every version of that question in 1.1 to 1.7 s.
Fragment test, every cell
Time from the caller’s last word to the first audible reply, one trial per cell. GPT-Live rows are highlighted.
More clips
More recordings from the same runs. Most are GPT-Live; where gpt-realtime did something worth hearing on the same sentence, it’s right below.
What I’d take from this
- If your app gives long instructions, GPT-Live’s handling of “yeah” and “mm-hmm” is a clear improvement over stopping on any sound.
- If callers need to cut in, listen to the “wait, stop” clips. Decide whether about 1.4 s of overlap is acceptable for your users.
- For dictation (phone numbers, codes, addresses), expect it to talk during pauses.
- With gpt-realtime the tradeoff is yours to set. With GPT-Live it’s fixed, and you debug from audio and transcripts because there are no turn events.
One model version each, synthetic caller voices, one client network, September 2026. Hosted models change; treat this as a dated measurement.
How I measured this
Every trial opened a fresh session. The harness streamed the caller’s audio in real time as 20 ms frames and rebuilt the playback timeline, so all times are when a listener would hear the audio, not when bytes arrived.
The two stop times aren’t measured the same way. For gpt-realtime, my client flushed queued audio when the server reported caller speech, so its stop time includes server detection, network and the flush. GPT-Live has no such event; its stop time is when its recorded audio went quiet.
To separate acknowledgments from replies I used the transcript. If everything GPT-Live said before the caller finished was words like “okay”, “got it”, “mm-hmm”, “go on” or “sure”, it counted as an acknowledgment. It’s a blunt rule; the tables under the charts show the counts.
GPT-Live’s transcript timestamps ran about 0.9 s ahead of its audio (median across 115 trials), so I shifted each transcript to line up with the first model audio. gpt-realtime transcripts have no word timings, so the quotes in its clips spread each message’s words evenly over its audio and drop what playback cut off.
Two things went wrong. My network dropped during the GPT-Live pause sweep and 61 trials failed to connect; I reran all of them. One more was cut off when I stopped the run and 2 were dropped because the harness fell behind real time, leaving 117 of 120. And my first stop detector missed GPT-Live’s habit of trailing off with a short fragment, which labeled some stops as “kept talking”. I fixed it and rescored every trial for both models; no gpt-realtime result changed.