GPT-Live 1 Needs a Backend Authority Boundary

The voice model should not own business authority

GPT-Live 1 separates the spoken interaction from the backend that reasons and uses tools. The voice model can listen and speak at the same time, keep the conversation moving, and delegate work without pretending that speech itself is the system of record. That is the useful architectural change.

The authority boundary does not move with it. OpenAI's delegation documentation says that the application owns permissions, confirmations, business records, and task state in both delegation modes. A booking is complete when the authoritative calendar accepts it. A case is routed when the support system records the assignment. A refund is pending until the named approver acts. The sentence the caller hears is a presentation of that state, not the state itself.

This makes the backend operating contract more important, not less. Define the source of truth, allowed actions, confirmation rule, accepted result, refusal path, human handoff, and recovery behavior before deciding how the voice frontend should delegate.

Choose the mode by who must inspect the result

Use Responses delegation when the managed request path fits and a backend result can return directly to GPT-Live. Use client delegation when your application must validate, redact, combine, route, or discard a result before the caller can hear it.

Responses delegation is the lower-operations starting point. GPT-Live prepares backend requests, manages the connection to the configured Responses model, and returns its result to the conversation. Your application still executes custom functions and still checks dependencies and required approvals. It is managed transport and context, not outsourced authority.

Client delegation is the stronger default when a result must pass an application policy before it becomes speakable. The application receives the delegation, reconstructs the task from its transcript and saved state, runs the chosen workflow, then decides what to return. The delegation event contains metadata rather than the task text, so this path requires deliberate transcript and state management.

Do not select the mode by model preference. Select it by where context is assembled, where policy is enforced, and who may reject the backend result.

Make the boundary explicit in code and state

Choose the delegation mode at session creation. OpenAI requires a new session to switch between Responses and client delegation, so the choice belongs in the workflow design rather than a last-minute prompt branch.

const session = {
  model: "gpt-live-1",
  delegation: { type: "client" },
  instructions: [
    "Keep the caller informed while backend work runs.",
    "Never claim an action succeeded without a verified result.",
    "Ask for clarification instead of guessing missing details."
  ].join(" ")
};

That configuration only establishes the conversational side. The application still needs a durable state machine for delegated work:

received -> authorized -> executing -> reconciled -> spoken
             |              |             |
           refused        uncertain     interrupted

Store at least an operation ID, a task revision, the GPT-Live delegation ID, the authorization decision, every tool receipt, the authoritative read-back, and the spoken-output observation. Increment the task revision when the caller corrects an address, date, quantity, or intent while work is running. A result produced for an older revision should be discarded or revalidated, not narrated as current.

The final transition matters because backend completion and spoken delivery are independent. OpenAI explicitly notes that a completed backend response does not prove the user heard it. For a reservation, verify both the booking record and the audio played after success. If the caller interrupts the confirmation, the booking may still exist even though the spoken outcome did not complete.

Keep approval evidence equally specific. The human approval gate should bind the exact proposal, not a vague permission to let the agent act later.

Measure the complete outcome, not pleasant audio

Track voice-session usage, backend usage, tool charges, and accepted business outcomes separately. GPT-Live 1 voice sessions cost $0.05 per minute, billed per second, while backend models and tools are billed separately according to the current model page.

The active session clock includes user speech, assistant speech, silence, and time spent waiting for backend work. Muting the microphone does not close the session. The WebRTC creation charge covers 15 seconds but is credited against the running session, so it should not be added twice.

OpenAI's cost guide gives an illustrative 90-second session: the voice portion costs $0.075 at the current rate. Add $0.02 of backend model and tool usage and the conversation total becomes $0.095. That example is arithmetic from published rates, not evidence that a business workflow will cost the same.

Use session.usage.updated as a cumulative duration snapshot. Do not sum the snapshots. After closing, retain the final seconds once, then join the nested response.completed usage for Responses delegation or the independent backend receipts for client delegation. Divide the joined total by reconciled bookings, acknowledged handoffs, or another workflow-specific accepted outcome. Cost per minute is an input. Cost per accepted outcome is the operating decision.

Test the failures that cross the boundary

Test the authority boundary with conversations that produce conflicting clocks. A natural voice demo can pass while the workflow underneath it is wrong.

The release gate should compare three things for every case: intended action, authoritative record, and played speech. A voice agent is ready when those three remain coherent through interruptions and failures, not when a sample call merely sounds natural.

GPT-Live 1 delegation FAQ