With this release, we’ve also reduced p95 latency by at least 25% across Realtime voice models through improved caching.
gpt-realtime-2.1 updates GPT-Realtime-2 with improved alphanumeric recognition, silence and noise handling, and interruption behavior. It supports speech-to-speech interactions with configurable reasoning effort, instruction following, and tool use for more complex voice-agent workflows.
gpt-realtime-2.1-mini is a mini reasoning model for faster, lower-cost realtime voice interactions.
A quick way to choose:
Use gpt-realtime-2.1 when you want the strongest realtime reasoning, tool use, instruction following, and voice-agent behavior.
Use gpt-realtime-2.1-mini when you want a faster, more cost-efficient option for realtime voice experiences.
Pricing
Model
Text input
Text cached input
Text output
Audio input
Audio cached input
Audio output
Image input
Image cached input
gpt-realtime-2.1
$4.00
$0.40
$24.00
$32.00
$0.40
$64.00
$5.00
$0.50
gpt-realtime-2.1-mini
$0.60
$0.06
$2.40
$10.00
$0.30
$20.00
$0.80
$0.08
Try them in the Playground and let us know what you build with these models and how they perform in your realtime voice workflows. Share your feedback, questions, and examples in the thread.
I tested gpt-realtime-2.1-mini against the previous/default gpt-realtime-mini.
The new mini model seems better in some areas: it respects prompt rules more consistently and appears to understand Portuguese names more accurately in voice calls.
However, I can’t migrate yet because it stopped triggering function tools in my SIP Realtime flow. With the same prompt, same tools, same SIP accept payload, and same backend handler, gpt-realtime-mini calls the function correctly, while gpt-realtime-2.1-mini collects and confirms the order but then says it cannot register/send it.
Faster speaking would be very welcome. I ask it to speak faster and it lasts briefly and isn’t particularly fast. I would like to be able to jack up the base rate similar to YouTube speed controls .25x - 4x.
While I think about it, it would also be great to have a tts voice optimised for clearly audible fast speech in English as, for me at least, the clarity usually breaks down between 2.5 and 4x. Primarily for multi tasking in codex with voice at a higher throughput
Realtime 2.1 is significantly harder to use for structured voice agents than realtime-mini
We’ve spent the last couple of weeks migrating a production outbound voice agent from realtime-mini to gpt-realtime-2.1-mini and, despite following the new prompting guide closely, we’ve hit a number of behavioural regressions.
Our use case is a highly structured telephony workflow (cold calling), where the agent follows explicit conversation steps, conditional branches and tool calls.
The main issues we’ve observed are:
Instruction leakage. The model frequently narrates its own behaviour:
“Let me continue with the call…”
“I’ll guide you through the next step…”
“Let’s move on to the next question…”
“Bringing you into the identity step…”
These are never in the prompt and are a poor UX for voice calls.
Commentary channel behaviour. It appears the model strongly wants to populate the commentary phase. Even with repeated instructions to emit nothing in commentary, it often invents transition narration. In some cases it even duplicates the final response into commentary.
Literal transition matching. Realtime 2 is much more literal than realtime-mini. We found that inline examples inside transition conditions (e.g. prospect agrees, e.g. "Yes") could cause the model to match the example itself rather than the semantic intent, occasionally skipping required conversation steps.
Conditional flow is less stable. Long prompts with many branching rules seem much more sensitive to wording than realtime-mini. We ended up rewriting almost every transition to focus on intent instead of examples.
More prompt engineering required for equivalent behaviour. After many iterations we have improved things considerably, but it has taken substantially more effort than with realtime-mini.
Ironically, after simplifying our prompt and temporarily reverting to realtime-mini, the behaviour became extremely stable again.
The worrying part is that realtime-mini is scheduled for deprecation. At the moment, our production experience is that it still behaves better than 2.1 for deterministic, structured voice workflows.
I’m curious whether others building production voice agents have seen similar issues, particularly around:
commentary leakage
transition narration
literal condition matching
deterministic multi-step dialogue
If anyone from OpenAI is reading, I’d also love to know whether these are expected characteristics of the new architecture, or areas that are still being actively improved. For structured conversational state machines, realtime-mini currently feels noticeably more predictable than gpt-realtime-2.1-mini, despite the newer prompting guidance.
