OpenAI pushed a second voice model into its API on September 10, 2026, and most developers still cannot tell it apart from the Realtime API they already use. The new model, gpt-live-1, handles the microphone and the speaker. A separate backend, either an OpenAI Responses model or your own agent, handles the thinking. That split changes how you architect a voice app, and it changes how you get billed. This tutorial walks through the full setup: creating credentials, choosing between WebRTC and WebSocket, wiring up ephemeral keys, streaming audio, delegating tool calls to a backend, and shipping a working voice agent you can test today. Expect to spend 60 to 90 minutes on the full build if you follow along step by step.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is OpenAI’s gpt-live-1 and How It Fits Into the Realtime API
gpt-live-1 is OpenAI’s full-duplex voice model, meaning it can listen and speak at the same time instead of waiting for silence before it responds. OpenAI shipped it generally available in the API on September 10, 2026, positioning it as a dedicated voice layer that sits in front of a reasoning backend rather than a standalone chat model. It had already become the default model behind ChatGPT Voice for Go, Plus, and Pro subscribers back in July 2026, with a smaller gpt-live-1 mini variant serving Free-tier users.
The distinction that trips people up is the difference between gpt-live-1 and the older Realtime API line (currently running models like gpt-realtime-2.1). The Realtime API handles voice input and output directly inside one model that also reasons and calls tools. gpt-live-1 does something narrower on purpose: it manages the spoken conversation, decides when to interrupt or wait, and hands off anything that requires real thinking, like a database lookup or a multi-step task, to a backend model over what OpenAI calls delegation. Apidog’s comparison of the two stacks frames it as a question of whether you want one model doing everything or two models split by responsibility, and for most production voice agents, the split model is easier to debug because you can swap the backend without touching the voice layer. OpenAI’s own getting-started guide for GPT-Live lays out the same architecture from the vendor side: choose a backend, connect a browser voice session, and let the voice layer decide when to hand off.
Launch coverage attributes gpt-live-1 with cutting erroneous interruptions by roughly 80% compared to earlier voice models, a number that comes from a launch partner rather than an OpenAI benchmark. Independent latency testing put gpt-live-1’s turn latency at around 0.798 seconds in one comparison, against 1.41 and 1.63 seconds for the other systems tested in that same benchmark. Whether those numbers hold up in your own network conditions is something you should verify yourself in Step 11 below, but they explain why teams building phone-based support bots and in-app assistants have been migrating off older realtime setups this quarter.
The broader realtime voice API market got more crowded the same week gpt-live-1 shipped. OpenAI’s own release calendar lists GPT-6 Astra landing September 3, DeepSeek-V4.1-Flash on September 10, and Claude Fable 5.1 going generally available September 1 with no preview stage, so the September 2026 stretch was unusually dense for model launches across the industry. Against that backdrop, gpt-live-1 stands out specifically because it targets voice interaction rather than general reasoning, competing less with GPT-6 Astra or Claude Fable and more directly with Google’s Gemini Live API and orchestration platforms like Vapi, Retell, and ElevenLabs that sit on top of foundation models to build phone and voice-agent products.
Real-World Use Cases: Where Teams Are Deploying gpt-live-1
Four patterns show up repeatedly in how teams are putting gpt-live-1 to work. Customer support lines are the most obvious one: a voice front end answers the phone, handles small talk and clarification, and delegates anything account-specific, like an order lookup or a refund request, to a backend agent that already has access to internal systems. Because gpt-live-1 bills separately from the backend, support teams can budget the voice-layer cost as a near-fixed per-call number and only watch the backend line item scale with call complexity.
In-app assistants are the second pattern, particularly for apps where typing is inconvenient, think fitness apps mid-workout, cooking apps with messy hands, or accessibility-focused tools for users who can’t easily use a keyboard. The full-duplex behavior matters more here than in phone support, since users expect to interrupt an in-app assistant mid-sentence the same way they’d interrupt a person.
Language practice and tutoring apps are a third use case worth mentioning, since low-latency turn-taking is what makes a conversation feel like practice rather than a translation exercise. And internal tools, voice-driven ticket triage, meeting-note capture, and hands-free warehouse or field-service logging, make up a fourth category where the backend delegation model fits naturally, since these tools usually already have an existing text-based agent that the voice layer can sit in front of with minimal rework. Teams that don’t want to manage WebRTC and session lifecycle code themselves increasingly reach for orchestration layers like LiveKit’s GPT-Live plugin, which wraps the connection handling shown in this tutorial behind a higher-level agents framework.
Security and Privacy Considerations for Voice Agents
Voice data carries different risk than text. Audio recordings can capture background conversations, identifying vocal characteristics, and sometimes sensitive information a user wouldn’t type into a chat box but will say out loud without thinking twice. Before you ship a gpt-live-1 integration to real users, decide explicitly whether you’re retaining raw audio, transcripts only, or nothing at all after the session ends, and reflect that choice in your privacy policy rather than defaulting to whatever OpenAI’s platform retains by default.
Ephemeral keys help on the credential side, since a leaked client-side key expires within roughly 60 seconds and can’t be reused for a second session, but they don’t protect the audio content itself. If your product operates in a regulated industry, healthcare intake lines or financial account verification are common examples, route your backend delegation through infrastructure that meets whatever compliance standard applies (HIPAA, PCI, or similar), since the voice layer forwarding audio to OpenAI doesn’t automatically make your entire pipeline compliant. Microsoft’s Azure OpenAI realtime audio path is one option specifically because it wraps model access in Azure’s existing compliance certifications, which is worth weighing against a direct OpenAI integration if your legal team requires it.
Consent matters too, and not just legally. Tell users explicitly when they’re talking to an AI voice agent rather than a human, and make it easy to reach a human alternative. Several jurisdictions have moved toward requiring AI-voice disclosure for customer-facing phone systems, and building that disclosure into your session’s opening instructions from day one is far easier than retrofitting it after a complaint.
Prerequisites: Accounts, SDKs, and Costs Before You Start
Gather these before you touch any code. Skipping the billing setup is the single most common reason a first gpt-live-1 session fails silently.
- An OpenAI platform account at platform.openai.com with billing enabled and a payment method on file (voice sessions are metered, not covered by free credits in most accounts)
- Node.js 18 or later if you’re building the browser-side client, or Python 3.9 or later for a server-only integration
- The official openai SDK installed at its latest release:
pip install --upgrade openaifor Python ornpm install openai@latestfor JavaScript - A backend framework to mint ephemeral keys server-side (this tutorial uses FastAPI, but Flask, Express, or any HTTP server works)
- A modern browser that supports WebRTC (Chrome, Edge, or Firefox) if you’re building a client-side voice widget
- Roughly $2 to $5 in OpenAI API credit for testing (gpt-live-1’s voice layer bills at $0.05 per minute, billed per second with no rounding up, plus separate charges for whatever backend model handles reasoning)
One budgeting note worth flagging early: the $0.05-per-minute rate covers only the front-end voice layer. If your backend delegates to a reasoning model for tool calls or long responses, that model’s own per-token pricing applies on top. A 10-minute test call with a handful of backend lookups typically runs well under a dollar, but production volumes add up fast if you don’t track both cost streams separately, which Step 12 covers.
To make the two-line-item billing concrete, here’s how a handful of common call lengths shake out on the voice layer alone, before any backend delegation cost is added.
| Call length | Voice-layer cost at $0.05/min | Typical use case |
|---|---|---|
| 1 minute | $0.05 | Quick status check or single-intent query |
| 3 minutes | $0.15 | Standard support call with one delegation round-trip |
| 10 minutes | $0.50 | Multi-step troubleshooting conversation |
| 30 minutes | $1.50 | Maximum single session length before a reconnect is required |
Backend delegation cost isn’t reflected in that table since it depends entirely on which model you route to and how much reasoning each call actually needs, but it’s rarely the dominant cost for short, well-scoped voice interactions. It becomes the dominant cost once your agent is doing heavy multi-step tool orchestration on every single call, which is a signal to revisit whether some of that logic can be simplified or cached rather than re-run from scratch each session.
Step 1: Create Your OpenAI Project and Generate an API Key
Log into the OpenAI platform dashboard and create a dedicated project for your voice agent rather than reusing a shared key from another app. Projects let you scope billing alerts and rate limits independently, which matters once you have a voice feature running alongside other API usage. Under API keys, generate a standard secret key and store it in an environment variable, never in client-side code. This standard key is what your backend uses to mint short-lived ephemeral keys in Step 4, and it should never reach the browser directly.
# .env file on your backend server, never commit this
OPENAI_API_KEY=sk-your-standard-project-key-here
OPENAI_ORG_ID=org-your-organization-idConfirm the key works with a basic request before building anything voice-related. If this fails, nothing downstream will work either, so it’s worth the 30 seconds.
curl https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY" | head -20Step 2: Choose Your Integration Path — WebRTC vs WebSocket
OpenAI’s documentation lays out two ways to connect, and picking the right one up front saves a rewrite later. According to OpenAI’s official documentation, “you can connect to the Realtime API in two ways: Using WebRTC, which is ideal for client-side applications (for example, a web app), and Using WebSockets, which is great for server-to-server applications (from your backend or if you’re building a voice agent over phone for example).”
Pick WebRTC if you’re building a browser-based voice widget, an in-app assistant, or anything where the user’s microphone talks directly to OpenAI with minimal hops in between. Pick WebSocket if you’re building a phone system integration, a server-side voice agent that processes audio from a telephony provider, or any architecture where your backend needs to sit in the middle of the audio stream. This tutorial covers both, since most production apps eventually need one browser flow and one server flow. OpenAI’s Realtime API getting-started guide covers the lower-level connection details for both transports if you need protocol-level specifics beyond what’s covered here.
Step 3: Install and Configure Your Development Environment
Set up two lightweight projects: a backend service that mints ephemeral keys and hosts your WebSocket logic, and a minimal frontend that captures microphone audio in the browser. Install dependencies for both sides.
# Backend (Python)
python3 -m venv venv
source venv/bin/activate
pip install --upgrade openai fastapi uvicorn python-dotenv websockets
# Frontend tooling (optional, if you want a bundler)
npm init -y
npm install openai@latestKeep the backend and frontend in separate directories from the start. It’s tempting to mix ephemeral-key generation into the same file as your WebRTC client code during testing, but that pattern tends to leak standard API keys into browser bundles once the project grows, which is exactly the security hole ephemeral keys exist to prevent.
Step 4: Generate an Ephemeral Client Key for Browser Sessions
Browser code should never hold your standard OpenAI API key. Instead, your backend requests a short-lived, single-use ephemeral key on behalf of the browser session, and only that ephemeral key ships to the client. Per OpenAI’s documentation, “connecting to the Realtime API from the browser should be done with an ephemeral API key, generated via the OpenAI REST API.” These keys expire roughly 60 seconds after issue and are valid for exactly one session, so you generate a fresh one for every new connection rather than caching them.
# backend_server.py
from fastapi import FastAPI
from openai import OpenAI
import os
app = FastAPI()
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
@app.post("/session")
def create_ephemeral_key():
session = client.beta.realtime.sessions.create(
model="gpt-live-1",
voice="Willow",
)
return {"client_secret": session.client_secret}Your frontend calls this /session endpoint first, receives the ephemeral key, and only then opens the actual voice connection. Never expose your standard key through this endpoint, and add authentication to it in production so random visitors can’t mint unlimited sessions against your billing account.
Step 5: Open a WebRTC Peer Connection From the Browser
With an ephemeral key in hand, the browser opens a WebRTC peer connection directly to OpenAI. OpenAI’s documentation confirms this handoff explicitly: “the browser uses the ephemeral key to authenticate a session directly with the OpenAI Realtime API as a WebRTC peer connection.” Your job on the client is to capture the microphone, attach it to the peer connection, and play back the audio track OpenAI sends in return.
// frontend.js
async function startVoiceSession() {
const res = await fetch("/session", { method: "POST" });
const { client_secret } = await res.json();
const pc = new RTCPeerConnection();
// Play remote audio from gpt-live-1
const audioEl = document.createElement("audio");
audioEl.autoplay = true;
pc.ontrack = (e) => (audioEl.srcObject = e.streams[0]);
// Send local microphone audio
const mic = await navigator.mediaDevices.getUserMedia({ audio: true });
mic.getTracks().forEach((track) => pc.addTrack(track, mic));
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
const sdpResponse = await fetch(
"https://api.openai.com/v1/realtime?model=gpt-live-1",
{
method: "POST",
body: offer.sdp,
headers: {
Authorization: `Bearer ${client_secret}`,
"Content-Type": "application/sdp",
},
}
);
const answer = { type: "answer", sdp: await sdpResponse.text() };
await pc.setRemoteDescription(answer);
}The pattern mirrors what OpenAI’s own developer docs describe: “the session connects over WebRTC in the browser or WebSocket on the server.” If audio doesn’t play back, check that autoplay permissions aren’t blocked by the browser, since Chrome and Safari both restrict unmuted autoplay without a prior user gesture.
Step 6: Connect via WebSocket for Server-to-Server Voice Agents
For telephony integrations, IVR replacements, or any case where audio arrives at your server rather than a browser, use the WebSocket path instead. Two different WebSocket endpoints exist depending on which layer you’re targeting: the general Realtime endpoint at wss://api.openai.com/v1/realtime?model=<model-name> for models like gpt-realtime-2.1, and a dedicated live-session endpoint at wss://api.openai.com/v1/live/sessions built around gpt-live-1’s session lifecycle. Both authenticate with a standard Authorization: Bearer header, since this is a server-side connection where your standard API key never touches untrusted code.
# server_voice_agent.py
import asyncio
import json
import os
import websockets
async def run_voice_session():
url = "wss://api.openai.com/v1/live/sessions"
headers = {"Authorization": f"Bearer {os.environ['OPENAI_API_KEY']}"}
async with websockets.connect(url, extra_headers=headers) as ws:
# First message on this endpoint must be session.start
await ws.send(json.dumps({
"type": "session.start",
"model": "gpt-live-1",
"voice": "Meridian",
"instructions": "You are a calm, concise support agent.",
}))
async for message in ws:
event = json.loads(message)
if event["type"] == "session.started":
print("Session ready:", event.get("session_id"))
elif event["type"] == "audio.delta":
# Forward raw audio bytes to your telephony stream here
pass
asyncio.run(run_voice_session())Treat the exact event field names above as illustrative of the documented flow (session start, session confirmation, audio streaming) rather than a copy-paste guarantee. OpenAI’s event schema evolves, so check the current guide on developers.openai.com before locking field names into a production build.
Step 7: Configure the session.start Event
The session.start message is where you set the personality and behavior of the voice layer. Based on OpenAI’s documented configuration categories, this event carries the model name, system instructions, which of the 12 available voices to use, audio format settings, and delegation configuration that tells gpt-live-1 which backend to hand reasoning off to. The 12 named voices shipped at launch are Quartz, Ripple, Vesper, Willow, Stone, Gleam, Meridian, Bossa, Tempo, Beacon, Delta, and Cinder, each with a distinct tone rather than a regional accent variant.
Keep instructions short and behavioral rather than encyclopedic. gpt-live-1 is optimized for conversational pacing, not for holding a long knowledge base in its own context. Anything that requires factual lookups belongs in the backend you delegate to in Step 9, not stuffed into the voice layer’s instructions field. The official gpt-live-1 model reference is the authoritative source for the current event schema, since OpenAI updates configuration options between releases.
{
"type": "session.start",
"model": "gpt-live-1",
"voice": "Stone",
"instructions": "Speak briefly. Confirm understanding before taking action. Escalate to the backend for anything requiring account data.",
"audio_format": {
"input": "client-default",
"output": "client-default"
}
}Step 8: Stream Audio and Handle Session Lifecycle Events
Once session.started comes back, you’re in a live conversation. Audio flows continuously in both directions rather than in discrete request-response turns, which is the whole point of a full-duplex model, it can process what the user is saying while it’s still speaking its own response and stop cleanly if interrupted. Your event loop needs to handle at minimum: the initial session.started confirmation, ongoing audio events in both directions, and a graceful session close.
Always close the session explicitly rather than just dropping the connection. OpenAI’s getting-started material for gpt-live-1 describes ending the conversation and closing the session as the step that finalizes usage accounting, so an abrupt disconnect can leave a session in a state where billing reconciliation takes longer or, in rare cases, undercounts the true session length on your side while OpenAI’s server-side clock keeps running until its own timeout fires.
Step 9: Delegate Reasoning and Tool Calls to a Backend Model
This is the architectural piece that makes gpt-live-1 different from a single all-in-one voice model. gpt-live-1 itself does not run tool calls or long reasoning chains, it recognizes when a request needs backend help and hands off. According to OpenAI’s developer documentation, once you attach a backend, you “attach tools, handoffs, and guardrails to the RealtimeAgent the same way you would attach them to a text agent.” That means your existing tool-calling patterns from text-based agent work carry over largely unchanged, you’re just routing the trigger through a voice session instead of a chat completion.
# backend_agent.py — the model gpt-live-1 delegates to
from openai import OpenAI
client = OpenAI()
def lookup_order_status(order_id: str) -> str:
# Replace with a real database or API call
return f"Order {order_id} shipped yesterday and arrives Thursday."
tools = [{
"type": "function",
"name": "lookup_order_status",
"description": "Look up shipping status for a customer order",
"parameters": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
}]
def handle_delegation(user_utterance: str):
response = client.responses.create(
model="gpt-6-astra",
input=user_utterance,
tools=tools,
)
return responseYou can point delegation at an OpenAI-hosted Responses model, as shown here, or at a fully custom agent you host yourself. Either way, keep the backend stateless per request where possible, since voice sessions can run up to roughly 30 minutes and a backend that accumulates memory leaks or unbounded context across that span will slow down mid-call.
Step 10: Build the Complete Working Voice Agent Project
Putting it together: your project needs three files. A backend that mints ephemeral keys and optionally hosts the delegation logic, a minimal HTML page with the WebRTC client from Step 5, and an environment file holding your standard key. Here’s the full backend, combining the ephemeral key endpoint with a delegation route the voice layer can call.
# main.py — complete backend for a working gpt-live-1 voice agent
import os
from fastapi import FastAPI
from fastapi.staticfiles import StaticFiles
from openai import OpenAI
app = FastAPI()
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
@app.post("/session")
def create_session():
session = client.beta.realtime.sessions.create(
model="gpt-live-1",
voice="Willow",
instructions="You are a friendly product support voice agent. "
"Keep answers under two sentences unless asked for detail.",
)
return {"client_secret": session.client_secret}
@app.post("/delegate")
def delegate(payload: dict):
response = client.responses.create(
model="gpt-6-astra",
input=payload["utterance"],
)
return {"reply": response.output_text}
app.mount("/", StaticFiles(directory="static", html=True), name="static")Drop the WebRTC frontend from Step 5 into a static/index.html file, run uvicorn main:app --reload, and open the page in a browser over HTTPS or localhost (WebRTC’s microphone permissions require a secure context). Speak into your microphone and you should hear gpt-live-1 respond within roughly a second under normal network conditions.
Step 11: Test Latency, Voices, and Interruption Handling
Before shipping, run three specific tests rather than a single happy-path conversation. First, interrupt the model mid-sentence and confirm it stops cleanly, since full-duplex behavior is the entire selling point and a model that talks over you defeats the purpose. Second, cycle through a few of the 12 available voices (Quartz, Ripple, Vesper, Stone, Gleam, and the rest) to pick the tone that fits your brand, since voice selection happens at session creation and can’t be changed mid-call. Third, measure round-trip latency from the moment you stop speaking to the moment audio starts playing back, ideally from the same network and region your real users will connect from, since published latency figures reflect specific test conditions that may not match yours.
If latency feels sluggish, check whether your WebRTC connection is routing through a TURN relay instead of a direct peer connection, which happens on restrictive corporate networks and adds meaningful delay. There’s no fix on the OpenAI side for this, it’s a network topology issue you solve with your own TURN server configuration.
Step 12: Monitor Usage and Control Per-Session Billing
gpt-live-1’s voice layer bills at $0.05 per minute, billed per second with no rounding up to a full minute, according to OpenAI’s launch pricing. Anything your session delegates to a backend reasoning model bills separately at that model’s own per-token rate, so your total cost per call is the sum of two line items, not one flat number. Set up a billing alert in the OpenAI dashboard scoped to your voice-agent project specifically, and log session duration and delegation call counts on your own side so you can reconcile OpenAI’s invoice against your expected usage.
A practical habit: cap maximum session length in your own code, even below OpenAI’s roughly 30-minute session ceiling, and force a graceful reconnect for genuinely long conversations. This keeps a single stuck or looping call from running up voice-layer minutes indefinitely if a user walks away without hanging up.
gpt-live-1 vs Realtime API vs Gemini Live: Pricing and Latency Compared
Choosing between OpenAI’s two voice-capable stacks and Google’s competing Gemini Live API comes down to how you want to structure your architecture and how predictable you need your bill to be. OpenAI’s gpt-live-1 is deliberately narrow, a voice front end that delegates thinking elsewhere, while the underlying Realtime API line (currently gpt-realtime-2.1) keeps voice and reasoning in a single model. Google’s Gemini Live takes a third approach with token-based billing rather than a flat per-minute rate.
| Dimension | OpenAI gpt-live-1 | OpenAI Realtime (gpt-realtime-2.1) | Google Gemini Live API |
|---|---|---|---|
| Pricing model | $0.05/minute voice layer, billed per second | Per-token, model-dependent | Token-based audio input/output pricing |
| Architecture | Full-duplex voice, delegates reasoning to backend | Single model handles voice and reasoning | Bidirectional low-latency audio/video sessions |
| Turn latency (as tested) | ~0.798s in one third-party benchmark | Not separately isolated in that benchmark | ~300-600ms in third-party comparisons (not an official Google figure) |
| Voice options | 12 named voices at launch | Standard Realtime voice set | Limited voice selection per third-party comparisons |
| Access | OpenAI API, model name gpt-live-1 | WebSocket/WebRTC via /v1/realtime | Vertex AI / Gemini API |
| Best fit | Predictable per-minute budgeting for voice-first apps | Apps that want reasoning and voice unified | Multimodal apps already on Google Cloud |
Note that the Gemini Live latency figures above come from third-party comparisons rather than an official Google benchmark, so treat both companies’ numbers as directional rather than a guaranteed SLA. If your product already lives on Google Cloud infrastructure, Gemini Live’s documented Live API is worth benchmarking against gpt-live-1 with your own traffic before committing either way. Teams standardized on Azure can also run the Realtime stack through Microsoft’s Azure OpenAI realtime audio guide, which wraps the same underlying models with Azure’s compliance and networking layer.
Common Pitfalls When Building With gpt-live-1
Most early gpt-live-1 integrations fail for a small set of repeatable reasons. Watch for these before they cost you a debugging afternoon.
- Mixing ephemeral keys with server-side sideband WebSockets. Ephemeral keys are built for browser WebRTC sessions. Developers on OpenAI’s community forum have reported that using an ephemeral key to create a call and then attempting a server-side sideband WebSocket lookup against that same call returns a 404, even though the ephemeral key opens a plain Realtime WebSocket session fine on its own. Use a standard API key for server-side sideband connections instead.
- Treating the $0.05/minute rate as your total cost. That figure covers only the voice layer. Backend delegation costs stack on top, and teams that forget this are consistently surprised by their first invoice.
- Still pointed at the deprecated Beta Realtime API. OpenAI deprecated the Beta Realtime API and its SDP exchange format on May 12, 2026. Older client libraries or copy-pasted code from pre-2026 tutorials will silently fail or throw obscure WebRTC negotiation errors.
- Expecting gpt-live-1 to call tools directly. It doesn’t. It delegates. If your voice agent seems to “forget” to look something up, check whether your delegation configuration is actually wired to a backend at all, rather than assuming the voice model itself is broken.
- Ignoring the 60-second ephemeral key expiry. If there’s any delay between minting the key and opening the WebRTC connection, for example a slow network request or a user who navigates away, the key can expire before it’s used, producing an authentication failure that looks unrelated to timing at first glance.
- Not testing on the actual network users will use. Latency benchmarks published by OpenAI or third parties reflect specific lab conditions. Corporate firewalls that force TURN relay, or mobile networks with variable jitter, can add hundreds of milliseconds that never show up in a clean office Wi-Fi test.
Troubleshooting: 9 Errors Developers Actually Hit
These are the specific failure modes showing up in OpenAI’s developer community and integration reports as of September 2026.
| Symptom | Likely cause | Fix |
|---|---|---|
| SIP accept returns 404 call_id_not_found | Regression reported on Realtime SIP integrations starting around September 10, 2026 | Check OpenAI’s status page and community forum for an active fix; avoid SIP accept flows until confirmed resolved |
| Sideband WebSocket lookup returns 404 after using an ephemeral key | Ephemeral keys aren’t meant for server-side sideband call lookups | Use a standard API key for the sideband/server-to-server leg |
| SIP Refer signaling doesn’t reach the far end | Known bug in Realtime SIP call-transfer handling | Avoid relying on SIP Refer for call transfer until OpenAI confirms a patch; handle transfer logic in your own telephony layer instead |
| WebRTC connection fails immediately with an SDP error | Client code still targets the deprecated Beta Realtime API’s SDP format | Update to the current Realtime API endpoints and drop any Beta-era SDK calls |
| “Unauthorized” error right after minting an ephemeral key | Key expired before the WebRTC offer was sent (60-second window) | Mint the key immediately before connecting, not ahead of time or on page load |
| Session drops unexpectedly around the 30-minute mark | Hitting the documented maximum session duration | Implement a graceful reconnect flow before the session ceiling, carrying over conversation context to the new session |
| Audio plays choppy or delayed | WebRTC routed through a TURN relay instead of a direct connection | Check your NAT/firewall configuration; direct peer connections are consistently faster than relayed ones |
| Backend delegation never triggers | Delegation isn’t configured in the session, or the backend endpoint is unreachable from OpenAI’s servers | Verify your delegation target is publicly reachable and correctly referenced in session setup |
| Bill higher than expected for a low call volume | Backend reasoning-model token costs weren’t tracked separately from voice-layer minutes | Log both cost streams independently and reconcile weekly against the OpenAI usage dashboard |
Advanced Tips for Scaling Voice Agents in Production
Once the basic flow works, a few adjustments separate a demo from something that survives real traffic. Run your ephemeral-key minting endpoint behind the same authentication as the rest of your app, since an open endpoint is an open invitation for anyone to run up your OpenAI bill. Log every session’s duration, voice used, and delegation call count to your own analytics rather than relying solely on OpenAI’s dashboard, since your own logs let you catch cost anomalies in near real time instead of waiting for a monthly invoice.
If you’re comparing this build against the broader agent-orchestration patterns covered in the OpenAI Agents API tutorial, the delegation model here follows the same tool-attachment logic, so code you’ve already written for a text-based agent largely transfers over once you swap the interface layer. Teams already running prompt-caching strategies from the LLM prompt caching guide should apply the same caching discipline to whatever backend model handles delegation, since repeated system instructions across thousands of short voice-triggered calls add up in token costs the same way they do in chat completions.
For teams evaluating whether to route delegation through GPT-6 Astra, Claude, or another backend model entirely, it’s worth benchmarking against the guidance in the GPT-6 Astra API tutorial and the Claude Fable 5.1 API guide, since latency on the backend leg adds directly to what the caller perceives as gpt-live-1’s own response time, even though the voice layer itself may be responding instantly.
Finally, build a fallback path. Voice infrastructure fails in ways text APIs don’t, dropped WebRTC connections, TURN relay slowdowns, microphone permission denials, and your product should degrade to a text chat input rather than leaving a user staring at a silent microphone icon.
Migrating an Existing Voice Integration to gpt-live-1
If you already have a voice feature built on an older Realtime model or the deprecated Beta Realtime API, plan the migration in stages rather than flipping the model name and shipping. Start by running gpt-live-1 in parallel with your existing setup behind a feature flag, routing a small percentage of sessions to the new model while you compare latency, interruption handling, and cost against your current baseline. Because gpt-live-1 separates the voice layer from reasoning, you’ll likely need to extract whatever tool-calling logic currently lives inside your single realtime model and move it into a standalone backend that gpt-live-1 can delegate to, which is the biggest structural change most teams encounter.
Pay close attention to any code still built around the Beta Realtime API’s SDP exchange format, since that path was deprecated on May 12, 2026, and community reports flag it as a source of obscure WebRTC negotiation failures for teams that haven’t updated their client libraries. Budget extra testing time for voice selection too. gpt-live-1’s 12 named voices don’t map one-to-one onto whatever voice set your previous integration used, so a side-by-side listening comparison before launch avoids an unpleasant surprise when your production voice suddenly sounds different to returning users.
Once you’re confident in parity, cut over fully and keep the old integration code available for a short rollback window rather than deleting it immediately. Voice regressions are harder to catch in automated tests than most backend changes, since tone, pacing, and interruption behavior are inherently subjective, so a staged rollout with real user monitoring catches issues that a test suite won’t.
Frequently Asked Questions
What is OpenAI’s gpt-live-1 model?
gpt-live-1 is a full-duplex voice model that OpenAI made generally available in the API on September 10, 2026. It handles spoken conversation, listening and speaking simultaneously, while delegating reasoning and tool use to a separate backend model.
How is gpt-live-1 different from the Realtime API?
The Realtime API (currently running models like gpt-realtime-2.1) handles voice and reasoning in a single model. gpt-live-1 splits those responsibilities, acting purely as the voice layer and handing off anything requiring real thinking to a backend Responses model or a custom agent.
How much does gpt-live-1 cost?
OpenAI prices the gpt-live-1 voice layer at $0.05 per minute, billed per second with no rounding to a full minute. Any backend model your session delegates to for reasoning or tool calls is billed separately at that model’s own rate.
Do I need a paid OpenAI plan to access gpt-live-1?
You need an OpenAI platform account with billing enabled and a payment method on file to call the API, since voice sessions are metered usage rather than covered by a flat subscription.
What voices are available in gpt-live-1?
Twelve named voices shipped at launch: Quartz, Ripple, Vesper, Willow, Stone, Gleam, Meridian, Bossa, Tempo, Beacon, Delta, and Cinder. Voice is set when you create the session and can’t be changed mid-call.
Can gpt-live-1 call functions or tools directly?
No. gpt-live-1 delegates any function calling or tool use to a backend model, either an OpenAI-hosted Responses model or your own custom agent, which you attach using the same tool-attachment pattern as a text-based agent.
Is gpt-live-1 available through Azure OpenAI?
Microsoft documents realtime audio support through Azure OpenAI in its Foundry platform, though the specific gpt-live-1 model name and availability should be confirmed against Microsoft’s current documentation, since Azure’s rollout schedule for new OpenAI models can lag the direct API by weeks.
How does gpt-live-1 compare to Google’s Gemini Live API?
The core difference is billing structure. gpt-live-1 charges a flat $0.05 per minute for the voice layer, while Gemini Live uses token-based pricing for audio input and output. Third-party comparisons put Gemini Live’s latency in the 300 to 600 millisecond range versus gpt-live-1’s roughly 0.798-second turn latency in one benchmark, though neither figure is a guaranteed number for your own traffic and should be tested independently.
Related Coverage
- Qwen Image 3.0 API Setup: 12 Steps, $0.03/Image [2026]
- OpenAI Agents API: Build AI Agents in 12 Steps [2026]
- AI Image Editing Workflow Setup: 12 Steps, 2 New Models [2026]
- LLM Prompt Caching: Cut API Costs 90% in 12 Steps [2026]
- AI Product Photography Setup: 12 Steps, $0.30 a SKU [2026]
