OpenAI kills the turn detector: what GPT-Live changes about voice AI architecture

OpenAI shipped GPT-Live, a new voice model generation it says it built in six months, and the interesting part isn't that it's faster — it's that it removes a component every voice assistant has relied on since the category existed: the turn detector.

The problem with turn-taking

Every voice AI you've used — Siri, Alexa, ChatGPT's earlier Advanced Voice Mode — runs a half-duplex pipeline. You speak, the system waits for silence, a voice-activity detector decides you're done, the audio gets transcribed, a language model reasons over the transcript, and only then does synthesis start and audio play back. Four sequential stages, one direction at a time. Each stage adds latency, and the silence-detection step in particular forces an awkward tradeoff: wait too long and the assistant feels sluggish; cut in too early and it interrupts you mid-thought.

This is why voice AI has always felt like talking into a walkie-talkie rather than talking to a person. Human conversation doesn't work in strict turns — we backchannel ("mhmm", "right"), we interrupt, we talk over each other briefly and recover. A pipeline built around detecting silence can't model any of that, because it's structurally committed to one speaker at a time.

What full-duplex actually means here

GPT-Live is full-duplex: it listens and generates speech on the same continuous audio stream, in both directions, at once. There's no discrete "user turn" followed by a "model turn" — instead there's a fast decision loop running multiple times per second, choosing among speak, keep listening, pause, interrupt, or invoke a tool. That loop is what replaces the turn detector. Instead of a binary gate (silence detected → now respond), the model is continuously re-evaluating what to do next, which is what lets it produce a mid-sentence "got it" without derailing its own generation, or stop cleanly when you cut in rather than finishing a sentence you've already interrupted.

The second architectural choice is where the reasoning happens. The fast conversational loop is deliberately kept light so it can run at that multiple-times-a-second cadence. Anything that needs real reasoning, web search, or multi-step tool use gets handed off to a separate frontier model — GPT-5.5 at launch — in the background, so a complex query doesn't stall the conversation while the heavier model works. The conversational layer keeps the exchange alive; the reasoning layer catches up asynchronously. That's a fairly clean separation of concerns: latency-critical dialogue control on one path, expensive cognition on another, connected by delegation rather than blocking calls.

What this buys, and what's still rough

OpenAI is positioning GPT-Live-1 and the lighter GPT-Live-1 mini as the default voice experience in ChatGPT across iOS, Android, and web, with GPT-Live-1 reserved for Go, Plus, and Pro subscribers and mini as the free-tier default — latency itself is being sold as the premium feature, which is a telling signal about how much engineering it takes to keep that decision loop fast. An API is described as "coming soon" via a gated signup, so outside developers can't build on this yet. OpenAI also reports GPT-Live-1 beating its own Advanced Voice Mode on GPQA, BrowseComp, and an internal telecom-style voice benchmark it calls τ³-Voice — though as with most vendor-reported benchmarks, I'd treat those as directional rather than definitive until independent evals show up. Live translation and rich in-conversation visual cards (weather, stocks, sports) ship at launch; video and screen-sharing don't, yet.

Why this matters beyond the demo

The part worth internalizing if you build with voice or real-time multimodal systems isn't the specific benchmark wins — it's the pattern: collapsing a multi-stage sequential pipeline into a continuous stream with a lightweight, high-frequency control loop, and pushing anything expensive off that loop entirely. That's the same shape you'd want in any system where responsiveness and depth are in tension — the fast path stays fast because it never waits on the slow path, it just delegates and keeps the interface alive. Voice happens to be where the latency stakes are most visible, because a few hundred milliseconds is the difference between a conversation feeling natural and feeling like a phone tree. But the architectural lesson — decouple the reactive loop from the reasoning engine — generalizes well past voice.

What I'm watching for next: real latency numbers once the API opens, and whether the full-duplex interruption handling holds up outside a curated demo, since that's usually where these systems show their seams first.