GPT-Live-1 Can Hear You Interrupt. That Does Not Cancel the Order.
OpenAI's full-duplex voice API separates conversation from backend work. That makes cancellation, consent and task state central engineering problems.
“Actually, don't book that” is easy for a person to understand and surprisingly difficult for a distributed voice agent to honor. The voice can stop mid-sentence while a booking request keeps running elsewhere. A caller hears cooperation; a backend may still be committing the reservation. The danger is not an awkward pause. It is a smooth conversation that conceals an unfinished or unwanted action.
OpenAI's September 10, 2026 release of GPT-Live-1 in the API brings that distinction into focus. The model can listen and speak simultaneously, while delegating reasoning and tools to a separate backend. OpenAI presents it as a more natural foundation for voice applications. Its developer documentation contains the more consequential sentence: interrupting speech does not automatically cancel backend work. This September 12 article examines that architecture, not a claim that the API launched today. The announcement and the live API guide establish those facts.
That is not a reason to dismiss full-duplex voice. It is a reason to stop treating a voice assistant as a text chatbot with a microphone attached. Conversation, computation and real-world actions now proceed on different timelines. A reliable product has to reconcile them explicitly.
The voice model is no longer the whole agent
A traditional chained voice application converts speech into text, sends that text to a reasoning model and converts the response back into audio. Each stage can add delay and lose conversational information. OpenAI says GPT-Live-1 instead reasons over incoming and outgoing audio together, handling the spoken interaction in one model while a backend performs deeper work. That is the architectural claim behind the launch, separate from any benchmark claim.
The backend can be a supported Responses model in managed delegation mode, or an application-controlled model, service or agent in client delegation mode. The developer does not have to use the same model for conversation and reasoning. This separation creates room to use a simpler backend for routine lookups and a more capable one for difficult cases. It also creates a new integration boundary that can fail independently. OpenAI's delegation documentation explains both modes.
For a retailer, the voice layer might acknowledge a caller's correction while an order service checks shipment status. For a travel service, the voice layer might continue discussing preferences while a planning agent compares itineraries. Neither example requires pretending that the voice model itself owns the order database or the airline reservation system.
The design becomes safer when that separation is visible in the application. The interface should distinguish listening, searching, awaiting confirmation and committing an action. Those are business states, not merely different animations for the same speech bubble. If they remain implicit, a developer can accidentally mistake a fluent acknowledgment for a completed transaction.
Full duplex changes the meaning of a turn
OpenAI says GPT-Live-1 supports interruptions, acknowledgments, natural pauses and background noise. The practical goal is to stop cutting people off when they hesitate and to stop forcing users into a rigid sequence of speak, wait and listen. In a language lesson, a pause may mean that the student is thinking. In a support call, an interruption may mean the agent has misunderstood a detail. The same silence can have different meanings.
The launch reports that Speak's early evaluations found substantially fewer interruptions than previous turn-based systems. That is a customer-reported result, not an independently established outcome for every language, accent or application. This article does not rank the model from the launch's benchmark charts. The operational question is whether a particular deployment can recognize the conversational behavior of its actual users. OpenAI attributes the Speak result in its announcement.
Full duplex does not eliminate the usefulness of explicit boundaries. OpenAI says the model still supports turn detection. A financial confirmation or a readback of an address may need a clear moment when the user approves a specific proposition. Natural conversation and explicit consent are compatible, but the application has to decide where conversational flexibility ends and a transaction protocol begins.
A test set should therefore contain unfinished sentences, self-corrections, background speakers and short acknowledgments. “Right” might confirm an address, indicate that the caller is still listening, or begin a correction. The correct interpretation depends on context. Measuring only transcription accuracy would miss the difference between correctly hearing a word and incorrectly treating it as authorization.
Two delegation modes create different responsibilities
Managed Responses delegation reduces implementation work by preparing backend requests, maintaining the relevant connections and returning results to the conversation. Client delegation gives the application more control over context, execution and which results reach GPT-Live. The distinction is not simply convenience versus complexity. It determines where the developer can inspect, redact or reject information before it is spoken. The mode comparison spells out those tradeoffs.
For a public information assistant, managed delegation may fit well. For a service handling sensitive account details, the developer may need to validate a backend result against an authenticated account before returning it. A travel assistant might combine a booking API and a separate policy engine. An enterprise service might need a deterministic approval checkpoint before an agent can write to an internal system.
In client mode, the documentation says the delegation event carries metadata rather than the task text itself. The application must construct backend context from transcripts and its own state. That is an important implementation detail: receiving a delegation event is not equivalent to receiving a complete, authoritative description of what the caller wants.
The mode is chosen when the session is created. Switching modes requires a new session. Developers should therefore make the decision around real requirements rather than assume they can freely change architectures halfway through a call. A product can vary supported backend settings within a mode, but that is different from changing who owns the orchestration contract.
A cancellation needs its own state machine
Imagine a hypothetical restaurant booking assistant. The caller asks for a table, the backend finds availability and the assistant asks for confirmation. The caller says yes, then immediately changes the date. By then, the original booking request may be queued, running, completed or awaiting a response. Stopping the assistant's voice does not tell the reservation service which of those states applies.
The application needs a durable record of the proposed booking, the specific confirmation, the request identifier and the final result. If the caller changes the date before commitment, it should invalidate the old proposal. If the booking has already been created, the system needs an explicit cancellation or modification operation. It should not claim that nothing happened merely because the spoken response was interrupted.
OpenAI assigns permissions, confirmations, private function execution and durable task state to the application. That wording in the live guide is an architectural boundary, not a minor disclaimer. The model can help interpret the request. The application must enforce whether an action is currently allowed.
This diagram shows a recommended booking-control pattern, not an undocumented GPT-Live feature.
flowchart TD
A[Caller requests reservation] --> B[Backend returns proposal]
B --> C[Application records explicit confirmation]
C --> D[Reservation commit]
D --> E[Read back actual booking state]
F[Caller interrupts or changes date] --> G[Invalidate pending proposal]
F --> H[Check whether commit already occurred]
H --> I[Cancel or modify through reservation service]
E --> J[Voice reports verified outcome]
I --> J
The same problem appears in refunds, appointment changes and subscription cancellations. Each action should be attached to a particular version of the user's intent. Otherwise a delayed result from an earlier request can arrive after the conversation has moved on and cause the assistant to announce or perform the wrong operation.
Silence is not a confidentiality control
The session documentation distinguishes instructions, quiet factual context and commentary intended to be spoken. That is useful for keeping a conversation natural: the assistant need not narrate every backend step. But OpenAI explicitly warns that quiet context can influence later speech and is not a privacy boundary. Credentials and information that must never be revealed should stay out of all those channels. The session guide makes that warning direct.
This matters because a developer may be tempted to send an entire internal record as silent context, assuming it is hidden from the user. The model still receives it. A later question, a misunderstanding or a malicious instruction could cause sensitive material to enter the conversation. The safer design sends only the facts the caller is authorized to receive and keeps private operational data in the backend.
For a customer-support deployment, the distinction could mean returning a permitted delivery date rather than the full order object, internal fraud flags and payment metadata. For an employee service, it could mean answering a benefits question without inserting unrelated personnel records into conversational context. Data minimization should happen before the voice model sees the result.
The same care applies to telemetry. A transcript, a tool log and a recorded call can each contain different sensitive information. Teams need retention and access policies for each artifact. A system that avoids speaking a secret but stores it in a widely accessible debugging dashboard has not solved the confidentiality problem.
The transcript is not proof of what the caller heard
OpenAI's documentation separates transcript events, audio playback and backend task state. Receiving assistant text does not establish that the corresponding audio was played to completion. A network interruption, a muted device or a caller speaking over the response can change what was actually heard. That distinction is especially important when an application relies on a disclosure or confirmation. The session lifecycle documentation describes those separate signals.
A transcript can also arrive in fragments with timing information. Developers should preserve ordering and distinguish the session timeline from wall-clock timestamps. A backend action may finish before its explanation is spoken, or the explanation may be interrupted while the action remains complete. Logs that collapse everything into a single text conversation make incident reconstruction harder.
Suppose an assistant says a cancellation has been requested but not yet confirmed. If the user hears only the first part of a longer explanation, they may infer a final outcome the system has not established. The product should use concise, unambiguous status language and provide a persistent confirmation through the application's ordinary channel when the transaction completes.
This is not an argument for recording every conversation indefinitely. It is an argument for deciding which events are necessary to prove consent and outcome, storing them appropriately and avoiding claims that a transcript alone cannot support. Speech quality is a user-experience metric. Transaction evidence is a separate requirement.
Phone integration is a deployment choice, not a checkbox
The live API offers browser-oriented WebRTC, server-side WebSockets and guidance for telephony paths. OpenAI's partner overview identifies integrations involving LiveKit, Twilio, Telnyx and Daily/Pipecat. The appropriate route depends on where audio already flows and which system owns the call. The partner guide and telephony documentation are the relevant references.
Existing communications platforms already manage important parts of that problem. LiveKit's agent documentation describes its agent framework, while Twilio's Voice documentation covers programmable calling infrastructure. Integrating a new voice model does not erase responsibilities around routing, disconnects, call transfer, recording policy and human escalation.
A company with an established contact center should test the complete path through its actual telephony provider. A clean browser demonstration does not establish performance on a noisy phone connection. The deployment should include dropped calls, reconnects, transfer failures and a caller who changes devices or loses audio while a backend operation continues.
Human escalation is part of that path. The receiving employee needs the verified account context, what the caller requested, what actions were attempted and which outcomes are still uncertain. A polished conversational summary is not enough if it omits a pending refund or falsely implies a booking was canceled. The handoff should carry structured task state as well as a readable explanation.
Five cents a minute is only the voice layer
OpenAI announced GPT-Live-1 at five cents per minute for the frontend voice layer. Its documentation says sessions are billed by duration, per second, while backend model and tool usage are billed separately. Buyers should not describe the headline rate as the complete cost of a support interaction. The launch pricing and model page establish the pricing boundary.
A long conversation with inexpensive lookups and a short conversation requiring substantial reasoning can have different cost profiles. Telephony charges, orchestration, monitoring and human escalation may also belong in the deployment budget. The useful measure is the cost of a correctly resolved case, with the acceptable service level defined in advance.
Natural conversation can affect that measure in both directions. Fewer interruptions may reduce repetition and frustration. A more engaging assistant may also keep a call open longer. Neither outcome should be assumed from the model's voice quality alone. Product teams need to observe whether users reach a verified resolution more efficiently, not simply whether they enjoy speaking with the assistant.
Backend selection should follow the same logic. A cheaper model that repeatedly misunderstands a policy can generate extra delegation cycles and human escalations. A stronger model may be justified for an exceptional case but unnecessary for a deterministic shipment lookup. The architecture allows separation; the evaluation has to determine where that separation is economical.
Prompting should not become a substitute for application policy
OpenAI recommends a short conversation prompt for tone and delegation behavior, with detailed business rules and tool workflows placed in the backend. That division makes sense because the voice model's immediate task is to manage conversation rather than carry the entire operating manual in every interaction. The prompting guide is the primary reference for that design.
The application still needs hard authorization checks. A prompt saying not to issue a refund above a threshold is not equivalent to a refund API that enforces the threshold. A prompt saying to ask for confirmation is not equivalent to a stored confirmation tied to a specific action. The model should cooperate with those controls, but it should not be the only place they exist.
Developers should also distinguish trusted instructions from retrieved material and user speech. A customer can quote a policy, a webpage can contain commands and a tool can return unexpected text. None should automatically gain the authority of the application's own instructions. Client delegation is useful when the service needs to filter such material before it becomes conversational context.
The result may look less magical in a demonstration because the assistant occasionally says it needs confirmation or cannot complete a request. That is a feature when the alternative is an unauthorized action. Full-duplex conversation should make the interaction less frustrating, not make the system less accountable.
A completed backend response can still leave a tool workflow unfinished
The live delegation documentation contains a detail that deserves attention from anyone connecting account systems. Forwarded Responses lifecycle snapshots can have empty output lists even when the application has collected function calls that still require results. OpenAI tells developers to track completed function-call items and their identifiers rather than infer the entire workflow from an empty terminal snapshot. The delegation guide documents this event contract.
That is the kind of integration error a fluent voice can hide. The caller hears an acknowledgment, the backend emits a lifecycle event and the application assumes the work is complete. In reality, a private function may not have run or its result may not have been submitted. The correct implementation must reconcile the function calls it received, the operations it authorized and the results it returned.
The same guide says that appending a function result does not automatically continue the delegated response. Developers must explicitly continue after supplying the required results. This is not a reason to avoid the API; it is a reason to test the event protocol rather than rely on an intuitive picture of an agent automatically handling every step.
For a customer account lookup, an integration test should prove that the assistant's spoken answer came from the completed authorized function, not from a conversational guess made while the function was pending. Inject a delayed result and a failed result. The assistant should communicate those states honestly and avoid using an old answer from a previous delegation as if it belonged to the current request.
Voice customization should not blur identity
OpenAI is expanding the available voices and offers a process for custom-voice access. Its session documentation lists language and regional influences for additional options and explicitly warns that regional influence is not a guarantee of accent fidelity. A business should evaluate those voices with the audience it intends to serve rather than assume a label establishes suitability. The voice options and configuration rules are the source.
A voice can change perceived authority as well as intelligibility. A calm, familiar-sounding assistant may encourage users to disclose more or assume that it represents a human employee. The product should clearly identify its automated nature and keep the explanation of its capabilities consistent with what the backend can actually do. Natural speech should not become a way to obscure that distinction.
For a multilingual support service, evaluation needs to cover names, addresses, product identifiers and language switching, not only pleasant sample sentences. The launch mentions alphanumeric understanding and keyword biasing, but those capabilities still require workload-specific checks. A misunderstood account identifier can be more consequential than an awkwardly pronounced sentence.
The choice of voice is also a session-lifecycle decision. OpenAI's documentation says changing it requires a new session. A service that offers accessibility preferences or a language transition needs to design that handoff deliberately, preserving the authorized task state without assuming every configuration field can be changed in place.
The final user experience should keep identity, speech style and authority separate. The same voice might answer a public question, retrieve private account information and request permission for a write operation, but those actions require different controls. A smooth tone cannot signal the distinction reliably by itself. Clear wording and application-enforced boundaries must do that work, especially when a caller is distracted, anxious or speaking through a poor connection.
The rollout test is a changed mind, not a perfect script
A useful evaluation suite should begin with messy but ordinary behavior. Ask for one appointment, correct the date halfway through, pause before giving a name, speak to someone else in the room, then return to the assistant. Check the resulting appointment record, not just the transcript. The model's advertised strength is interaction, so interaction failures belong in the acceptance criteria.
A separate test should exercise delayed and contradictory backend results. Let an old availability check finish after the caller has chosen a different time. Return an error after the assistant has optimistically acknowledged a request. Disconnect audio during confirmation. The expected behavior should be specified before the run, including when the system must stop and ask a person to resolve uncertainty.
For language-learning applications, the evaluation should instead emphasize hesitation, correction and the learner's opportunity to complete a thought. A tutor does not need the same transaction machinery as a booking agent, but it still needs to avoid interpreting background speech as the learner's response. The same model can support different products without sharing a single success metric.
GPT-Live-1's launch makes a clear technical proposition: separate natural conversation from the backend work needed to fulfill a request. The best implementations will preserve that separation all the way through logging, permissions, billing and user communication. When a caller changes their mind, the assistant must do more than sound as if it understood. It must know which work is still pending, which action already happened and what it can truthfully promise next.