The OpenAI Realtime API is what developers use to build speech-to-speech voice agents: one model listens, talks, keeps track of the conversation and can call tools, which suits phone or website agents that need fast replies and let callers interrupt. GPT-Live is OpenAI's newer split design, where GPT-Live handles listening and speaking and a separate backend decides how to do the work and which tools to call.
If you're planning a voice agent for your phones or website, the difference changes how it's built, how it behaves while it's busy and how you're billed. Everything here comes from OpenAI's Realtime guide, its GPT-Live migration guide and its voice cost guide. For the wider picture first, see the OpenAI API in plain English.
Realtime API or GPT-Live: the short version
| Question | Realtime API | GPT-Live |
|---|---|---|
| Who picks the tools? | The voice model itself | A backend: a hosted Responses model, or your own existing agent |
| What OpenAI points it at | Barge-in, low first-audio latency, natural turn taking and realtime tool use | Full-duplex conversations with a separate delegated backend |
| How the instructions are written | One prompt for voice and task | A Live prompt for speaking style, plus a backend prompt for the work |
| The end of each spoken reply | Marked by events such as response.output_audio.done and response.done | No matching event; your app tracks playback in the audio player |
| While the backend works | The voice model selects and waits on functions itself | GPT-Live can keep talking while the backend works |
How a voice session runs
OpenAI's getting-started guide describes the usual browser flow in four steps:
- Your server creates an ephemeral client secret for the session, so your main key never sits in the browser.
- Your website creates a RealtimeSession.
- The session connects over WebRTC in the browser, or WebSocket on a server.
- The agent handles audio turns, tools, interruptions and handoffs inside that session.
The guide starts developers with the Agents SDK and keeps lower-level connection guides for teams that want direct control. The current Realtime model in its example is gpt-realtime-2.1. If you still have an old beta Realtime integration, OpenAI says to move it to the GA interface before doing anything new.
One detail worth passing to your developer: safety identifiers. If your app identifies individual callers, OpenAI recommends sending a stable, privacy-preserving value, such as a hashed internal user ID, in the OpenAI-Safety-Identifier header. It's not required. The benefit is that if one caller misbehaves, OpenAI can target enforcement at that user rather than your whole organisation.
Two ways to hand off the thinking
GPT-Live offers two delegation modes:
- Responses delegation: a hosted Responses model reasons about the task and picks tools. Your application still runs your own functions and returns the results. OpenAI suggests this as a starting point if your Realtime model currently selects functions.
- Client delegation: you keep your existing agent or orchestrator. Your app supplies the context, starts the work and decides which results go back to GPT-Live.
OpenAI's worked example is an appointment assistant. The caller asks what's free on Friday, GPT-Live hands that to the backend, the backend asks for a check_availability lookup, your app runs it, and GPT-Live talks the caller through the slots. Two practical warnings come out of that guide. Stopping speech doesn't stop backend work, so if a caller asks to cancel, your backend has to handle it. And a spoken goodbye alone leaves the connection open; ending a call needs an end-call capability.
What you're billed for, second by second
This is the part business owners should read twice. OpenAI's cost guide says GPT-Live voice sessions are billed per second at the current model rate, not rounded up to the next minute. Active session time includes the caller speaking, the assistant speaking, both being silent, and the backend working. Muting the microphone doesn't close the session.
Creating a WebRTC session bills 15 seconds of voice time while it starts up, and that's credited against the session once it runs, so a 90-second call isn't billed as 105 seconds. Backend models and tools are billed separately, as they would be without voice.
The catch in plain words: a slow tool costs you voice seconds while the caller waits. OpenAI's suggested fixes are to give the voice model the context you already hold before the call starts, such as an order number and its status, to cut tool waiting with a faster model option and parallel tool calls, and to close the session when the conversation ends. For long jobs with client delegation, the backend can keep working while the voice session is closed.
Moving an existing voice agent across
OpenAI's advice is to keep your existing tool implementations, permission checks and saved task records. Before migrating, it suggests recording:
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
- Your tools and business rules, including the conditions for each action.
- Where audio, typed text and images enter your application.
- Decisions that depend on the sound itself, not only the words.
- When speech may start, when it must stop, and what must finish before audio plays.
- Your permissions, confirmations and guardrails, and where they're enforced.
- The records and task progress that must survive a dropped call.
- Baseline conversations from today's system, to compare against afterwards.
Then split your old prompt instead of copying it wholesale: speaking style and when to delegate go in the Live prompt, detailed workflows and tool use go in the backend. If your app already uses Chat Completions and only needs audio in and out, OpenAI also documents an audio route in Chat Completions.
Build it or buy it?
I'd buy a voice agent for most small businesses rather than build one. This stack is powerful, but it's a developer project with prompts, guardrails, billing and call handling to own. Only build on GPT-Live if voice is the product you sell, or a core part of it. Skip it if you just need calls answered and appointments booked: compare the voice agent platforms you can buy first. And if all you need is transcripts, a speech-to-text API is a much smaller job.
If you're weighing a voice agent for your phones and want to know what it will take, that's the kind of AI enablement I help with. I run AI training and workshops for teams, and help businesses with AI enablement and workflow automation, so the busywork runs itself and people get time back. Most of that work is with SaaS marketing teams and small businesses. Here's how we can work together.
Frequently asked questions
What is the OpenAI Realtime API?
It's OpenAI's API for speech-to-speech voice agents. The model works directly with audio, keeps conversation state and can call tools, with support for interruptions and natural turn taking.
What is GPT-Live?
GPT-Live is OpenAI's voice model that handles listening and speaking while a separate backend decides how to complete tasks and which tools to call.
How is GPT-Live billed?
Voice sessions are billed per second, including silence and backend wait time. Creating a WebRTC session bills 15 seconds up front, credited against the running session. Backend model and tool costs are billed separately.
Do I need to rebuild my tools to move to GPT-Live?
No. OpenAI says to keep your existing tool implementations, permission checks and saved task records, and move the tool definitions to the backend.
What is an OpenAI safety identifier?
A stable, privacy-preserving value such as a hashed user ID, sent in the OpenAI-Safety-Identifier header. It's recommended, not required, and helps OpenAI act on one user rather than your whole organisation.
