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"
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
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
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
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.
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
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?
Top comments (0)