GPT-Live's Full-Duplex Voice Needs a Mobile Interruption Test, Not Just a Conversation Demo

OpenAI released GPT-Live on July 8, 2026, introducing a full-duplex voice architecture that can listen and speak simultaneously. A developer argues that the polished desk demo is insufficient and provides a detailed mobile test plan covering interruptions, route changes, backgrounding, and permission revocations to ensure robust performance.

OpenAI introduced GPT-Live on July 8, 2026 and describes it as a full-duplex voice architecture: it can listen and speak at the same time. GPT-Live-1 and GPT-Live-1 mini are rolling out in ChatGPT Voice, while API availability was described as coming later. Primary source: OpenAI, “Introducing GPT-Live” https://openai.com/index/introducing-gpt-live/ . Full duplex changes the mobile failure surface. The app may hold microphone input, play output, detect interruptions, and continue background work concurrently. A polished desk demo does not answer what happens when a phone call arrives, Bluetooth disconnects, the app backgrounds, or permission changes. This is the test plan I would run before shipping a full-duplex voice workflow. It is a plan, not a report of measured GPT-Live API behavior. device: "physical device model" os: "exact OS version" app build: "immutable build" voice model: "product/model label visible during test" audio route: "speaker | wired | bluetooth" network: "wifi | 5g | constrained" battery start: "percent" low power mode: false microphone permission: granted background permission: "record actual setting" A result without device, route, and network context is difficult to reproduce. php idle - connecting - listening <- speaking - reconnecting - paused by system - ended - error Track three channels separately: The UI should never imply “listening” after the OS revoked microphone access. Use a harmless scripted conversation and timestamp every event: T+00 connect on phone speaker T+10 user speaks while assistant is speaking T+20 switch to Bluetooth headset T+35 background the app for 30 seconds T+65 return to foreground T+80 trigger an incoming call or system audio interruption T+95 decline/end interruption T+110 disable microphone permission in Settings T+130 return to app and attempt resume T+150 restore permission and reconnect Expected observations must be written before the run: | Event | Expected audio | Expected UI | Recovery | |---|---|---|---| | user barges in | output yields or behavior is explicit | listening/speaking state updates | conversation remains coherent | | route changes | no private audio on old route | new route named | no duplicate playback | | app backgrounds | follows declared product policy | background state visible on return | no fake continuity | | phone interruption | capture/playback pauses | system interruption shown | explicit resume | | permission revoked | microphone stops | actionable permission error | Settings path and reconnect | | network loss | no endless “listening” | reconnecting with cancel | bounded retry or end | Do not assume the platform permits indefinite background capture. Verify OS policy and application behavior for the exact build. Capture: connect ms speech start to response audio ms barge in to output stop ms route switch gap ms reconnect ms battery delta percent thermal state changes unexpected audio after interruptions For every latency metric, report the number of trials and percentiles. Five hand-picked fast runs are not a mobile performance result. A small log format: {"run":3,"event":"bluetooth disconnect","at ms":35211,"ui":"reconnecting","old route audio ms":0,"recovered ms":1840} Redact transcript content, account identifiers, and network details before sharing logs. The highest-value UI test is simple: Given the session is listening When microphone permission becomes denied outside the app And the app returns to foreground Then capture is stopped And the UI does not show listening And an accessible error explains how to restore permission And retry is disabled until permission is available Also verify the OS microphone indicator disappears. If app state and OS state disagree, trust the OS observation and file the mismatch. Full-duplex should not mean ambiguous capture. The interface needs a reachable stop control, a clear listening indicator, and a predictable rule for whether delegated work continues after audio ends. Test these separately: One red button that sometimes means all four is difficult to reason about during an interruption. GPT-Live makes natural overlapping conversation a timely design target. On mobile, acceptance depends on a less glamorous result: after every OS interruption, the microphone, speaker, task, and UI return to one truthful state. Which interruption breaks your current voice experience most often: route changes, backgrounding, calls, or permission recovery?