No Screen Share, No Video: Building Around GPT-Live's Launch Limitations

New defaults ship with holes. GPT-Live — OpenAI's full-duplex voice experience that became the default for ChatGPT on July 8, 2026, replacing Advanced Voice Mode — is a genuinely better conversational model. It also launched with a specific, public set of limitations, and for anyone building voice skills, those limitations are the most useful part of the announcement.

Why? Because a limitation in the default consumer app is a specification for where a purpose-built skill has room to win. GPT-Live is one product making one set of tradeoffs for hundreds of millions of users. Your skill can make different tradeoffs for a narrow, valuable use case. The trick is knowing exactly where the default stops — and then deciding, feature by feature, whether to lean on GPT-Live, fall back to legacy voice, or build your own agent on the Realtime API.

This is a route-to-X-when-Y piece. Let's map the gaps.

Key Takeaways

• No video or screen sharing at launch. For those, GPT-Live users fall back to legacy voice mode. Any workflow that needs the model to see is not served by GPT-Live today.
• No consumer GPT-Live API yet. It's "coming soon" behind a signup form with no date. Production voice agents get built on the Realtime API (gpt-realtime), not GPT-Live.
• No macOS desktop voice. Desktop pulled back on voice months earlier; GPT-Live is iOS, Android, web, and a CarPlay upgrade.
• Predefined voices only. No custom voices or cloning for consumers — a hard constraint, not a gap you can fill by asking nicely.
• Each limit is a routing decision. Match the requirement to the surface: GPT-Live for default conversation, legacy for vision, your own Realtime skill for anything production or specialized.

What GPT-Live actually ships with

Start from the facts, because the strategy falls out of them. As of July 2026, GPT-Live:

• Is full-duplex — it listens and speaks at once, backchannels, and yields to interruptions. This is the headline strength.
• Runs on GPT-Live-1 for paid tiers (Go, Plus, Pro) and GPT-Live-1 mini for Free users, and delegates hard requests to a frontier model (GPT-5.5 for now) in the background.
• Supports real-time translation and can show on-screen visual cards (sports, weather) alongside the voice reply.
• Runs on iOS, Android, and web, plus a CarPlay upgrade — but not macOS desktop voice.

And here's what it explicitly does not do at launch:

• No video input. It can't watch a live camera feed.
• No screen sharing. It can't see what's on your display.
• No consumer API. You can't build on GPT-Live itself yet.
• No custom or cloned voices. Predefined voices only, with safeguards that block impersonation.

Note the distinction the launch draws: on-screen cards (the model showing you a weather card) are not the same as vision (the model seeing your screen or camera). GPT-Live can render visuals; it can't perceive them.

Route-to-X-when-Y: the decision list

Take each requirement your skill has and route it:

The pattern: GPT-Live owns default conversation; the Realtime API owns everything you need to control, specialize, or ship.

The vision gap is the clearest opening

Of all the limits, "no video, no screen share" is the one most likely to matter to a skill builder, because so many high-value voice use cases are really voice-plus-sight: walk me through this error on my screen, look at this part and tell me what's wrong, read this label.

GPT-Live can't do that today — users fall back to legacy voice mode. But the underlying Realtime stack does document image inputs (added in the original gpt-realtime GA back in Aug–Sep 2025). So if your skill needs sight, you don't wait for GPT-Live to add video; you build on the Realtime API and feed it images directly.

The strategy writes itself: pick a use case where GPT-Live's missing vision is disqualifying, and where a still image is enough (you rarely need a full video stream — a snapshot at the right moment usually is). That's a defensible skill: it does the one thing the default explicitly can't.

GPT-Live (consumer):     voice ✓   backchannels ✓   video ✗   screen-share ✗   your-tools ✗
Realtime API (build):    voice ✓   backchannels ✓   images ✓  function-calling ✓  MCP ✓

The platform gap: mobile and the car, not the desktop

There's a quieter limit worth reading carefully. GPT-Live runs on iOS, Android, and web, and shipped with a CarPlay upgrade — but there's no macOS desktop voice (desktop pulled back on voice mode months earlier). The pattern is telling: OpenAI is betting voice on the surfaces where people's hands and eyes are busy — the phone in your pocket, the car — and away from the desktop, where a keyboard is right there.

For a skill builder, that's a signal about where voice fits, not just where GPT-Live runs. The CarPlay investment says driving is a first-class voice context, and a driving context makes the "no video, no screen share" limit almost irrelevant — you can't look at a screen anyway. If your voice skill targets hands-busy, eyes-busy moments (driving, cooking, on the move), you're aligned with where the platform is heading and the vision gap barely costs you. If your skill assumed a desktop-at-a-keyboard user, reconsider: that's the surface OpenAI is retreating from for voice, and it's usually the surface where typing beats talking anyway.

The "no consumer API yet" gap is a timing bet

OpenAI says a consumer GPT-Live API is "coming soon" — signup form, no date. This is the most misread limitation. It does not mean you can't build full-duplex voice agents today. It means you build them on the Realtime API, which already shipped gpt-realtime-2.1 and -2.1-mini on July 6 with p95 voice latency cut by at least 25%.

So the decision is not "wait or don't." It's "which surface":

• Waiting for the GPT-Live consumer API makes sense only if you specifically need the exact consumer packaging (the app's UX, its default frontier delegation) and have nothing to build in the meantime. There's no date, so this is an open-ended bet.
• Building on the Realtime API now gives you full-duplex voice, function calling, MCP, image inputs, and SIP — under your control, in production, today. For almost every builder, this is the answer. The consumer-vs-API comparison lays out exactly which capabilities live where.

Turning limits into a skill roadmap

Here's how to act on all of this concretely:

1. List your skill's hard requirements — vision, custom voice, production control, specific platforms.
2. Route each against the table above. Any row that lands on "Not GPT-Live" is either a reason to build on the Realtime API or a reason to descope.
3. Find your wedge. The best voice skills target a requirement GPT-Live explicitly can't meet — vision via image inputs, telephony via SIP, or a specialized model like translation.
4. Design the fallback. If a user reaches for a capability you don't support, downgrade gracefully — the same way GPT-Live falls back to legacy voice for video rather than failing.
5. Respect the hard blocks. Predefined voices only, impersonation safeguards — these are not gaps to route around. Build inside them. The voice-safety checklist covers what that means for publishing.

The takeaway

Launch limitations read like weaknesses. For a builder, they read like a map. GPT-Live is going to own the default voice conversation for a very large number of people — competing with it head-on on "general voice chat" is a losing game. But it launched without video, without screen share, without a consumer API, and without custom voices, and each of those is a place where a focused skill on the Realtime API does something the default cannot.

Don't build the thing GPT-Live already does well. Build the thing its launch notes say it doesn't do — and route everything else to the surface that fits. Browse what voice-first builders are shipping in the agents and workflows channels, and read the rest of the ChatGPT Voice series for the deeper dives on each gap.