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

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”. 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. Record the environment 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" Enter fullscreen mode Exit fullscreen mode A result without device, route, and network context is difficult to reproduce. Define observable states idle -> connecting -> listening speaking -> reconnecting -> paused_by_system -> ended -> error Enter fullscreen mode Exit fullscreen mode Track three channels separately: audio input — is the microphone active? audio output — what route is speaking? task state — is a delegated/background operation still running? The UI should never imply “listening” after the OS revoked microphone access. Interruption sequence 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 Enter fullscreen mode Exit fullscreen mode 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. Measurements 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 Enter fullscreen mode Exit fullscreen mode 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} Enter fullscreen mode Exit fullscreen mode Redact transcript content, account identifiers, and network details before sharing logs. Failure fixture: stale microphone indicator 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 Enter fullscreen mode Exit fullscreen mode Also verify the OS microphone indicator disappears. If app state and OS state disagree, trust the OS observation and file the mismatch. Privacy and recovery boundary 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: mute microphone — stops new audio input; stop speaking — stops output; end conversation — closes the voice session; cancel task — stops any background agent work. 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?