How to build voice agents with GPT-Live (and what to do until the API ships)

GPT-Live is the most significant shift in voice architecture since streaming pipelines. It listens and speaks at once, decides many times a second what to do, and hands deeper reasoning to a background model while the conversation keeps flowing. For developers, the important news is twofold: this changes how you design a voice agent, and the API to build on it directly is not available yet. This guide covers what changes, what you can build today, and how to be ready on day one. Evalgent works with teams shipping production voice agents through exactly this kind of transition.

GPT-Live: OpenAI's full-duplex voice model, launched July 8, 2026, that listens and speaks simultaneously and delegates deeper reasoning to GPT-5.5 in the background, currently available inside ChatGPT with a developer API planned.

The honest status: no GPT-Live API yet

Before any architecture discussion, the practical fact: as of launch, GPT-Live ships only inside ChatGPT. There are two models — GPT-Live-1 for paid users and GPT-Live-1 mini for free users, replacing Advanced Voice Mode — but no developer API to call them directly. OpenAI has said an API is planned soon; it is not here today.

That means any tutorial promising "install the GPT-Live SDK" right now is fiction. What you can do today is build on the current Realtime API, understand what full-duplex changes, and design so that adopting GPT-Live later is a swap rather than a rebuild. That is the honest, useful position, and it is the one this guide takes. The OpenAI voice agents guide documents what is available now.

Full-duplex vs turn-based: what actually changes

The core shift is the death of the turn. Traditional voice agents are half-duplex: the caller speaks, an endpointer detects the end of their turn, and then the agent responds. Builders spend real effort tuning voice-activity detection and end-of-turn thresholds to make that handoff feel natural.

Full-duplex removes that handoff. GPT-Live listens and speaks continuously, deciding many times a second whether to talk, keep listening, backchannel, or pause. It is not waiting for silence; it is judging the conversation in real time. For builders, this means the endpointing and VAD tuning that consumed so much effort largely goes away — the model owns those decisions now. What replaces it is a different design problem: shaping how the agent behaves during overlap, interruption, and thinking. Our piece on full-duplex voice agents covers the architecture in depth.

Delegation to GPT-5.5: designing for "thinking while talking"

The second architectural idea is delegation. GPT-Live keeps the conversation flowing while handing hard reasoning, search, or agentic work to GPT-5.5 in the background, then folds the result back in. The conversational model stays responsive; the heavy thinking happens out of band.

For builders, this creates a new design surface: the gap while the background model thinks. A well-designed agent holds the floor naturally during that gap — acknowledging, filling, staying present — rather than going silent. You are no longer just choosing a model; you are designing how the agent behaves in the seconds between a hard question and its answer. Reasoning tiers give you a dial on this. GPT-Live exposes Instant, Medium, and High tiers: Instant uses the fast model, while Medium and High invoke deeper thinking. Each tier trades latency for depth, and choosing the right one per interaction is a core design decision, closely tied to your latency budget.

What you can build today on the Realtime API

While GPT-Live's API is pending, the current Realtime API already supports real speech-to-speech voice agents, and it is where you build today. It gives you a low-latency, streaming, tool-capable foundation that maps cleanly onto what GPT-Live will offer.

You can build a full voice agent now: a realtime session over WebRTC or WebSocket, streaming audio in and out, with tool calling for actions like lookups and bookings. You choose between a chained pipeline — speech-to-text, then an LLM, then text-to-speech — and a speech-to-speech model that handles audio directly, a tradeoff our best LLM for voice agents guide unpacks. Building on the Realtime API today gives you a production agent and a codebase already shaped around streaming and realtime sessions, which is most of the work of being GPT-Live-ready.

Chained vs speech-to-speech, and the latency dial

One real decision when building today is whether to use a chained pipeline or a speech-to-speech model, and it previews the tradeoff GPT-Live formalizes. A chained pipeline runs speech-to-text, then an LLM, then text-to-speech as separate stages. It gives you control and easy swapping of each component, but every stage adds latency, and the seams between them are where errors compound.

A speech-to-speech model takes audio in and emits audio out directly, collapsing those stages. It is faster and more natural, closer to how GPT-Live behaves, but you trade away some per-stage control. For most new production agents aiming at a full-duplex future, leaning toward speech-to-speech is the more forward-compatible choice.

Either way, latency is the dial you are really tuning, and GPT-Live's reasoning tiers make that dial explicit. Designing your agent so latency is a deliberate choice — fast where the caller needs immediacy, deeper where the answer needs thought — is exactly the muscle GPT-Live will ask you to use. Get comfortable with that tradeoff now, and the tiered model will feel familiar.

A migration-readiness checklist for the GPT-Live API

The goal is to make adopting GPT-Live a swap, not a rewrite. A few design choices now will make that true.

Keep your model and session layer abstracted, so the conversational model can be replaced without touching your business logic. Build tool calling cleanly and assert on it, since full-duplex makes tool-call timing trickier. Stop over-investing in custom VAD and end-of-turn tuning, because full-duplex will own those decisions. Design an explicit "thinking" state now, so you already have a natural way to hold the floor during delegation. And instrument the agent for overlap and timing, not just transcripts, so you can measure the behaviors full-duplex introduces. Do these, and the day the GPT-Live API lands, you adopt it in an afternoon.

Common mistakes to avoid now

A few habits from the half-duplex era will actively slow a GPT-Live migration, and it is worth dropping them today.

The first is pouring engineering into custom voice-activity detection and end-of-turn heuristics. That work is about to be owned by the model, so deep investment there is effort you will throw away. The second is hard-coding a single model deep into your business logic, which turns a future swap into a rewrite. The third is treating the agent as request-response — build in an explicit "thinking" state now, because full-duplex will demand one. And the fourth is instrumenting only transcripts. Full-duplex behavior lives in overlap and timing, so if your logging cannot see an interruption or a silent gap, you will be blind to exactly the failures that matter. Avoiding these keeps you moving toward full-duplex instead of away from it.

The catch: full-duplex needs new testing

Here is the part that is easy to miss in the excitement. The same full-duplex behavior that makes GPT-Live feel human introduces failure modes that older testing cannot catch. When the model listens and speaks at once and delegates mid-sentence, it can lock in a caller's outdated intent, talk over them, or go silent while it thinks.

These are not hypothetical. The Full-Duplex-Bench-v3 benchmark documents them, and the numbers are real — strong models succeed on fewer than 59% of self-correction scenarios, and silent gaps appear in nearly a quarter of delegated cases. If you build a full-duplex agent, you have to test for these, and transcript-level tests will not surface them. That is a whole discipline of its own, which is why we wrote a companion piece: how to test GPT-Live voice agents.

Conclusion

GPT-Live changes the architecture of a voice agent, not just the model behind it — full-duplex removes the turn, and delegation adds a new gap to design around. But the developer API is not out yet, so the winning move today is to build on the Realtime API and design for an easy migration.

Get GPT-Live-ready by abstracting your model layer, dropping custom endpointing work, and designing an explicit thinking state now. And plan to test the new full-duplex failure modes from day one, because the behavior that makes these agents feel human is exactly the behavior that breaks in ways old tests miss.

Frequently asked questions

How do you build a voice agent with GPT-Live?

You cannot build directly on GPT-Live yet, because its developer API is not available — it launched inside ChatGPT on July 8, 2026, with an API planned soon. Build on the current Realtime API today, which supports streaming speech-to-speech agents with tool calling, and design your model and session layer so adopting GPT-Live later is a swap rather than a rebuild.

Is the GPT-Live API available?

Not at launch. GPT-Live shipped inside ChatGPT with two models, GPT-Live-1 for paid users and GPT-Live-1 mini for free users, but there is no developer API to call them directly yet. OpenAI has said an API is planned soon. Until it arrives, the Realtime API is what developers build production voice agents on.

What is the difference between GPT-Live and the Realtime API?

GPT-Live is a full-duplex model that listens and speaks at once and delegates deeper reasoning to a background model, currently available only in ChatGPT. The Realtime API is the developer-facing way to build streaming voice agents today. When the GPT-Live API ships, it is expected to bring full-duplex behavior to developers; until then, you build on the Realtime API.

What does full-duplex change for developers?

Full-duplex removes the clean end-of-turn that half-duplex agents wait for, so the voice-activity detection and endpointing tuning developers used to invest in largely goes away — the model owns those decisions. In its place, you design how the agent behaves during overlap, interruption, and the pause while it delegates reasoning. It is a shift from tuning turn detection to shaping realtime conversational behavior.

How do you prepare for the GPT-Live API?

Abstract your model and session layer so the conversational model can be swapped without touching business logic, build and assert on tool calling, stop over-investing in custom endpointing, design an explicit "thinking" state to hold the floor during delegation, and instrument for overlap and timing rather than just transcripts. These choices turn a future GPT-Live migration into a swap rather than a rewrite.

What can you build with the Realtime API today?

A full production voice agent: a realtime session over WebRTC or WebSocket, streaming audio in and out, with tool calling for actions like lookups and bookings. You can choose a chained speech-to-text, LLM, and text-to-speech pipeline or a speech-to-speech model that handles audio directly. It gives you a codebase already shaped around streaming, which is most of the work of being GPT-Live-ready.

How does GPT-Live delegation work?

GPT-Live keeps the conversation flowing while handing hard reasoning, search, or agentic work to GPT-5.5 in the background, then folds the result back into the conversation. The conversational model stays responsive while the heavy thinking happens out of band. For builders, the design challenge is the gap while the background model thinks — a good agent holds the floor naturally instead of going silent.

What are GPT-Live reasoning tiers?

GPT-Live exposes three reasoning tiers — Instant, Medium, and High — that trade latency for depth. Instant runs on the fast model for immediate responses, while Medium and High invoke deeper thinking for harder questions. Choosing the right tier per interaction is a core design decision, because it directly shapes both the latency the caller feels and the correctness of the answer.