Where voice assistants used to get stuck

Voice assistants often froze up when calling tools. The model would go silent right after triggering a function call, the user would assume the call had dropped, speak over it or just hang up, and the conversation state would get scrambled — leaving you with half a result and having to call back and start over.

Reasoning lands in the mini tier — how it fixes the silence problem

This section is the heart of the launch: reasoning gets pushed down to the cheap mini tier, and paired with a "verbal heads-up," it directly fixes the silent-dropout problem from the last section.

What "reasoning" means here

Reasoning means the model thinks through, before it speaks, how to handle a request and whether it needs to call a tool — instead of blurting out whatever it hears first. The mini tier now supports function calling too, so it can plan a step ahead, call your function, and then give the answer.

Breaking down a single tool-calling exchange, the sequence looks like this:

Five reasoning levels — trading off latency against quality

Reasoning effort is configurable, five levels from low to high: minimal, low, medium, high, xhigh. Low is the default, keeping latency down for simple exchanges; the higher the effort, the more latency and output tokens it uses. OpenAI recommends most production voice assistants start at low and only dial it up for harder tasks.

How to choose between the two models

The short version: use the full gpt-realtime-2.1 for the strongest realtime reasoning, tool-calling, instruction-following, and voice-assistant behavior; use gpt-realtime-2.1-mini when faster and cheaper is good enough.

25% lower latency, and how caching saves money

This launch's latency improvement comes from caching optimizations. And caching doesn't just save time — it saves a lot of money too.

What "p95 latency" means

p95 latency is: line up every request's response time from fastest to slowest, and take the value at the 95th percentile. It represents how long the slowest 5% of users actually waited — not the average. For realtime voice, the choppiness users actually notice hides in that slow tail. Cutting that tail by at least 25% makes the conversation feel noticeably more responsive.

Why cached hits drop the price so much

Cached input means: this turn of the conversation continues from a system prompt or history that's already been processed, and the service recognizes "this part's already been computed," reusing it instead of recomputing — so the price drops sharply. The system prompt gets cached after the first turn, so the longer the conversation and the more it reuses, the more it saves. Here's the gap between cached and fresh pricing for the mini's audio input:

All three models' prices, in full

All prices are per million tokens, across text, audio, and image. Click a tab to switch categories — the mini column is highlighted.

What it's good for

Four typical scenarios, each showing how reasoning, tool-calling, and the recognition improvements come into play:

What integration looks like

The minimal setup: the server first mints a short-lived client credential (the standard API key stays server-side and never gets exposed), and the browser uses that short-lived credential to connect directly over WebRTC, setting up a microphone track and a data channel to send and receive events.

Pick the connection method by scenario: browsers and phones that capture and play audio directly use WebRTC; servers that already have a raw audio stream (call centers, media pipelines) use WebSocket; telephony voice agents use SIP.

// Server: mint a short-lived client secret
const r = await fetch("https://api.openai.com/v1/realtime/client_secrets", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    session: {
      type: "realtime",
      model: "gpt-realtime-2.1-mini",
      instructions: "You are a support agent. Reply in one or two short sentences.",
      reasoning: { effort: "low" },
      tools: [
        {
          type: "function",
          name: "lookup_account",
          description: "Look up a customer account by email.",
          parameters: {
            type: "object",
            properties: { email: { type: "string" } },
            required: ["email"]
          }
        }
      ],
      tool_choice: "auto"
    }
  })
});
const { value: EPHEMERAL_KEY } = await r.json(); // pass this to the browser

// Browser: connect to the Realtime API over WebRTC
const pc = new RTCPeerConnection();

const audioEl = document.createElement("audio");
audioEl.autoplay = true;
pc.ontrack = (e) => { audioEl.srcObject = e.streams[0]; };

const mic = await navigator.mediaDevices.getUserMedia({ audio: true });
pc.addTrack(mic.getTracks()[0]);

const events = pc.createDataChannel("oai-events");
events.addEventListener("message", (e) => console.log(JSON.parse(e.data)));

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

const sdp = await fetch("https://api.openai.com/v1/realtime/calls", {
  method: "POST",
  body: offer.sdp,
  headers: {
    Authorization: `Bearer ${EPHEMERAL_KEY}`,
    "Content-Type": "application/sdp"
  }
});
await pc.setRemoteDescription({ type: "answer", sdp: await sdp.text() });

This ships through the GA endpoint, not beta. If your app distinguishes between end users, OpenAI recommends adding an OpenAI-Safety-Identifier header to credential-issuing requests (e.g., a hash of the internal user ID), so abuse monitoring can pinpoint the specific user instead of mistakenly flagging the whole account.

Where it shines, where it's limited

By OpenAI's own numbers, here's both sides of this launch:

This time's change: the model learned to "think before speaking" and can keep talking while it looks things up — opening with "let me check that." The user hears a voice the whole time and won't assume the call dropped.

How does it pull off talking and working at once without falling apart? It's the new "reasoning" underneath. What that whole flow looks like — see the figure below.

Reasoning means the model thinks it through in its head before speaking: how should it respond, does it need to call a tool to check something. Once it's figured that out, it gives you a verbal heads-up first, then acts. Below, using XiaoHu calling to check an order as the scenario, the old and new flows are laid side by side.

Same order-lookup request: the old way goes completely silent while "calling the tool," so the user assumes it dropped and interrupts, getting only half the result; the new way says "let me check that" first, then talks while it works, all the way through.

The longer it thinks, the more thorough — but also slower. Reasoning has five levels (minimal / low / medium / high / xhigh), defaulting to the fastest-that's-good-enough low tier, dialing up only for harder tasks.

"How many times faster" doesn't mean much to most people — converting it to money makes it click. For the same million tokens of voice input (roughly, a chunk of words), uncached costs $10, while a "cache hit" (reusing parts already computed earlier in the conversation instead of recomputing) costs just $0.30.