Consumer vs API: GPT-Live Powers the App, gpt-realtime Powers Your Product
OpenAI shipped two voice things in one week. GPT-Live is the ChatGPT app; gpt-realtime is the API you build on. Here's which track to pick and why it matters.
Consumer vs API: GPT-Live Powers the App, gpt-realtime Powers Your Product
In one week in early July 2026, OpenAI shipped two voice launches with confusingly adjacent names. On July 6, the developer-facing gpt-realtime-2.1 and gpt-realtime-2.1-mini landed in the Realtime API. On July 8, the consumer-facing GPT-Live rolled out in the ChatGPT app, replacing Advanced Voice Mode as the default. Same domain, same week, similar names — and completely different things.
If you're building a voice agent, getting this distinction right is the difference between a stack that ships and one that stalls waiting for an API that isn't public yet. GPT-Live is a product. gpt-realtime is a building material. You consume one and build on the other. This piece draws the line cleanly, then tells you which track to commit to.
Key Takeaways
- GPT-Live is the consumer app — the voice mode inside ChatGPT, now the default for iOS, Android, and web users. It has two variants: GPT-Live-1 for paid tiers (Go, Plus, Pro) and GPT-Live-1 mini for Free users.
- gpt-realtime is the developer API —
gpt-realtime-2.1andgpt-realtime-2.1-mini, the thing you actually build voice agents on. Available now. - The GPT-Live consumer API is only "coming soon" — a signup form, no date. Do not architect production voice agents around it yet.
- Build on gpt-realtime today. It's GA, it supports function calling, remote MCP, image inputs, and SIP telephony, and it's where the p95 latency improvements shipped.
- The tracks may look alike but diverge on control — the API gives you reasoning-effort settings, tool wiring, and caching economics the consumer app abstracts away.
Two launches, two audiences
Start with the mental model, because everything downstream depends on it.
GPT-Live is a feature of the ChatGPT app. Your mother uses it. It's the tap-to-talk experience that now, as of July 8, 2026, listens and speaks in full duplex, delegates hard questions to a frontier model in the background, does live translation, and shows on-screen visual cards for things like weather and sports. It runs on GPT-Live-1 for paying users and GPT-Live-1 mini for the free tier. You do not "build on" GPT-Live any more than you build on the Gmail app. You use it.
gpt-realtime is an API endpoint. It's what a developer calls to get a low-latency, speech-to-speech model that a product can wrap. The July 6 release — gpt-realtime-2.1 and its -mini sibling — is a versioned model you send audio to and get audio back from, with knobs for reasoning effort, function calling, and connection paths like remote MCP and SIP. This is the build surface. When this series says "build a voice agent," this is the thing meant.
The naming makes them feel like a matched consumer/pro pair. They're not two editions of one product. They're a product and a platform that happen to share a launch window.
The trap: the GPT-Live API that isn't public yet
Here's where teams get burned. It's natural to assume that because GPT-Live is the shiny new consumer experience, there's a GPT-Live API you can call to get the same full-duplex magic in your own product. As of July 2026, there is a signup form for a "coming soon" consumer GPT-Live API — and that's it. No date. No SLA. No docs to build against.
If you plan your architecture around "we'll just call the GPT-Live API," you're planning around vapor. The responsible read is: the consumer GPT-Live API does not exist for production use yet, and you should not put it on your roadmap's critical path.
What does exist, today, is the Realtime API. It's generally available, it's versioned, and it already has the capabilities most voice agents need. So the decision is simple.
The decision, in a table
| Question | GPT-Live (consumer) | gpt-realtime (API) |
|---|---|---|
| What is it? | Voice mode in the ChatGPT app | Model endpoint in the Realtime API |
| Who's the audience? | End users | Developers building products |
| Can I build on it? | Not yet — API "coming soon," no date | Yes — GA today |
| Full duplex? | Yes, in the app | Yes, via the Realtime API |
| Function calling / tools? | Abstracted from you | Yours to wire (function calling over live voice) |
| Reasoning control? | Not exposed | Configurable reasoning effort (minimal → xhigh) |
| MCP / image / SIP? | N/A | Remote MCP, image inputs, SIP telephony |
| Caching / cost control? | Not your concern | Cached vs fresh audio pricing you manage |
| Variants | GPT-Live-1, GPT-Live-1 mini | gpt-realtime-2.1, gpt-realtime-2.1-mini |
The pattern is clear: if you want control — over tools, reasoning, cost, and integration — you want the API. The consumer app trades that control for a polished, opinionated experience you can't reach into.
Which track to build on
For any product voice agent, the answer as of July 2026 is gpt-realtime, and it's not close. Three reasons:
It exists. You can call it today. The consumer GPT-Live API can't be built on until it ships, and "coming soon" is not a launch date. Building on GA infrastructure is the only defensible choice for anything with a deadline.
It gives you the control surface a real product needs. A consumer app decides for you: which voice, how much it reasons, when to call a tool. A product agent needs to make those calls itself. gpt-realtime exposes configurable reasoning effort (minimal, low, medium, high, xhigh — with low as the default), function calling over live voice, and the connection paths — remote MCP, image inputs, SIP telephony — that let a voice agent do real work. The function-calling deep-dive walks through building an agent that reasons mid-conversation on exactly these controls.
The economics are yours to manage. The API surfaces the cost knobs that matter at scale — cached audio input runs dramatically cheaper than fresh, and the mini variant adds reasoning at a lower price point. The consumer app hides all of that because a consumer doesn't care. A product owner cares a lot; the latency-and-cost analysis in this series digs into why caching and model choice decide both your latency and your bill.
The one legitimate reason to care about GPT-Live as a builder: it's the reference experience. It's what your users' expectations are now calibrated against. When someone talks to your voice agent, they'll unconsciously compare it to the full-duplex, interruptible, backchanneling ChatGPT they used that morning. That bar — not the API — is what you're actually building toward.
Mapping your existing agents onto the API
The reason this distinction is good news, not just a gotcha: if you've already built agents or workflows that do useful work over text, gpt-realtime lets you put a voice front-end on them without rebuilding the logic. The Realtime API's remote MCP support means a voice agent can call the same MCP servers your text agents already use, and its function-calling support means your existing tools carry over. This is the whole thesis of wiring realtime voice to your existing skills: voice is a new interface on capability you may already own.
Practically, if you're deciding where to start:
- Have text agents that work? Wrap them with gpt-realtime and MCP. Don't wait for the consumer API. Your skill catalog and loop recipes are the raw material.
- Building voice-first from scratch? Design against gpt-realtime's control surface — reasoning effort, function calling, caching — from day one.
- Tempted by "GPT-Live API coming soon"? Note it, sign up for the waitlist, and build on gpt-realtime anyway. When the consumer API arrives, you'll evaluate it against a working product, not a slide.
A gut-check before you commit
If you're still unsure which track a given project belongs to, run it through three questions:
- Is a human tapping a microphone in an app you don't control? That's GPT-Live territory — you're not building it, your users are already using it. Your job is to be at least as good.
- Do you need to decide what the model does — which tool, how hard to reason, what it costs? That's gpt-realtime. Control means the API.
- Does it have a ship date? If yes, it's gpt-realtime, because the consumer GPT-Live API has none. "Coming soon" can't be on a critical path.
There's a subtler point buried in the variant names. GPT-Live has GPT-Live-1 and GPT-Live-1 mini; gpt-realtime has 2.1 and 2.1-mini. The mini/full split exists on both tracks, but it means different things. On the consumer side, mini vs full is decided for the user by their tier — Free gets mini, paid gets full. On the API side, mini vs full is a decision you make per workload, trading cost and latency against capability. That's the difference between the two tracks in miniature: the app decides for you, the API hands you the dial. The latency-and-cost breakdown covers when to reach for the API's mini variant.
The takeaway
Two launches, two days apart, two audiences. GPT-Live is the app your users tap; gpt-realtime is the platform your product runs on. The consumer API that would blur the line is still "coming soon," which means for anyone shipping voice this quarter, the choice makes itself: build on the Realtime API, treat GPT-Live as the experience bar your users now expect, and don't let a shared launch week trick you into betting on an endpoint that isn't public. Once you've picked the API track, the next question is what you actually do with it — starting with an agent that reasons mid-conversation and calls your functions over live voice.