OpenAI's full-duplex voice mode on the ChatGPT desktop app: what holds up and what doesn't

Full-duplex voice on the ChatGPT desktop app works well enough for quick back-and-forth, but it falls apart the moment you need it to shut up and listen. Interruption handling is the good part — you can cut in mid-sentence and it actually stops. Latency is fine on a wired connection and bad on flaky WiFi. I wired it into my daily workflow for a week and here's where it earned a spot and where it got closed.

Does the interruption handling actually work?

Yes, and this is the feature that matters. In the old voice mode you'd talk over the model and it kept going like a podcast on autoplay. In the new full-duplex mode you say "stop" or just start talking and it cuts within maybe 300-500ms. That's the difference between a demo and a tool. According to TechCrunch's report, OpenAI is pushing this as the more natural conversational mode, and on interruption specifically that claim holds.

The gotcha: it interrupts *itself* too. Background noise, a cough, a coworker walking by — the model treats ambient sound as a turn boundary and stops talking mid-answer. In an open office it's unusable without a headset. With a decent noise-gating mic it's fine. So budget for hardware, not just software.

What broke?

Latency is inconsistent. On ethernet, first-token audio comes back fast enough to feel like a phone call. On hotel WiFi I saw 2-3 second gaps where I couldn't tell if it heard me, so I repeated myself, which then triggered a double response. There's no visible "I'm listening" state that's reliable enough to trust, so you end up guessing.

The other break: it's a conversation tool, not a work tool. Ask it to read back code and it mangles symbols — it'll say "underscore" and "open paren" in a stream that's impossible to follow. Anything structured (JSON, a stack trace, a file path) is better in text. Voice is for thinking out loud and rubber-ducking, not for consuming precise output.

Where it actually fit my workflow

One concrete win: I used it to talk through architecture decisions while pacing away from the keyboard. Describe the problem, let it push back, no typing. That's genuinely useful and I kept it for that. What I did *not* keep it for: anything I needed to copy, anything with exact identifiers, or anything in a shared room.

Also worth noting — desktop makes this better than mobile because you've got a real mic setup and you're already at your machine when a follow-up needs to become a text prompt. The handoff from voice to "okay now show me the diff" is one click away.

Should you use it?

Use it if you have a headset and a quiet room and you think better out loud. Skip it if you're in an open office or you expect it to dictate precise output. It's a good conversational front-end and a bad transcription surface. For me it survived the week for one narrow use — talking through problems — and got closed for everything else. That's a real feature, not a gimmick, but it's narrower than the pitch.

FAQ

Does the full-duplex voice mode handle interruptions well?

Yes. You can cut in mid-response and it stops within roughly 300-500ms, which is the main upgrade over the old mode. The downside is it also stops on background noise, so a noise-gating mic or headset is close to required.

Is it good for reading back code or structured output?

No. It verbalizes symbols like "underscore" and "open paren" in a stream that's hard to follow, and file paths or JSON come out mangled. Keep structured output in text and use voice for discussion.

Is desktop better than mobile for this?

For me, yes. Desktop gives you a real mic setup and a one-click handoff to text when a follow-up needs an exact prompt or you want to see a diff. Mobile lacks that quick transition.