Mercury 2 vs GPT-Realtime 2.1

GPT-4o Realtime is a search term. GPT-Realtime 2.1 is the model you would ship in August 2026.

Mercury 2 is a text component at $0.25 input and $0.75 output per million tokens. GPT-Realtime 2.1 is a native speech-to-speech system at $4/$24 text and $32/$64 audio.

We will not declare a latency winner. Mercury's published times are text generation. GPT-Realtime operates on audio.

OpenAI's current model catalog has moved on from the older product name. People still search "GPT-4o Realtime", which is why the requested URL keeps it.

One of these is a component

Table 1 Download CSV

Question	Mercury 2	GPT-Realtime 2.1
Input and output	Text in, text out	Text, image, and audio in, text and audio out
Voice design	Cascaded STT → LLM → TTS	Native realtime speech-to-speech
Context window	128K	128K
Tool use	Supported	Function calling supported
Structured output	Schema-aligned JSON documented	Not supported on the model card
API path	OpenAI-compatible chat completions	Realtime, WebRTC/WebSocket/SIP-compatible platform paths
Text price per 1M tokens	$0.25 input / $0.75 output	$4 input / $24 output
Audio price per 1M tokens	Not applicable	$32 input / $64 output
Comparable voice latency	Requires full-stack test	Requires full-stack test

Mercury 2 is one component. GPT-Realtime 2.1 is a voice model with a transport-oriented API surface. Compare system against system rather than one token-rate cell against another.

That distinction also explains the price columns. Mercury's rate looks roughly sixteen times cheaper on text input, and the number is real, but it prices a smaller share of the work. Two vendors are still missing from that side of the table, and they bill in minutes rather than tokens.

Mercury keeps every speech vendor replaceable

Inception's Mercury 2 documentation describes a diffusion reasoning model with adjustable reasoning, tool use, schema-aligned JSON, a 128K context window, and an OpenAI-compatible endpoint. Official pricing is $0.25/$0.75 per million input and output tokens.

Control is the attraction. Teams choose their speech recognizer, voices, regional deployment, interruption detector, and telephony provider, then swap the text model later without rebuilding the audio layer.

Boundaries are the cost. Your application must decide when the caller stopped speaking, carry partial transcripts, stream text into speech, cancel audio during an interruption, and maintain tool state across components.

Those same boundaries produce a better audit trail, which is the underrated half of this decision. Applications can retain the transcript, the exact Mercury request, tool arguments, returned text, and synthesized audio identifiers as separate events. That separation is what lets an engineer say whether a bad call began with recognition, reasoning, a tool, or pronunciation. The benefit only appears if one trace links every component, so build the trace before the pilot rather than after the first complaint.

GPT-Realtime 2.1 has fewer seams

GPT-Realtime 2.1 accepts and produces audio directly. OpenAI says the model improves alphanumeric recognition, silence and noise handling, and interruption behavior over GPT-Realtime 2. It supports configurable reasoning and function calling, with a 128K context window and up to 32K output tokens.

The model card lists text pricing at $4 per million input tokens, $0.40 cached input, and $24 output. Audio pricing is $32 per million input tokens, $0.40 cached input, and $64 output. Audio and text token accounting differ, so a text-only calculator cannot predict the voice bill.

Native audio preserves signals a transcript discards: hesitation, tone, pacing, pronunciation, and overlapping speech. Alphanumeric handling matters more than it sounds, because account numbers, postcodes, and order references are where cascaded stacks most often fail and where callers least tolerate a retry.

Coupling is the trade. Model, voice behavior, audio billing, and realtime API semantics all arrive from one provider, and a change to any of them lands in production together.

Operational testing should include session reconnects, audio cancellation, tool results arriving after the caller changes the request, and calls crossing the context limit. Removing component calls does not remove state management. It relocates it.

Mercury's three latencies are not one clock

Three numbers circulate for Mercury 2, and taken at face value they contradict each other.

Table 2 Download CSV

Source	Figure	What it appears to time
Inception voice report	About 300 ms reasoning trace	One internal segment, not a full response
Inception voice report	Under about 500 ms customer-observed	A tuned deployment on a chosen workload
Our runtime feed	3.53 s to first answer	A public endpoint, standard prompt, review date

None of these is dishonest. The spread between them is the actual lesson. A reasoning-trace segment excludes most of a request. A customer-observed figure reflects a deployment somebody optimized, on prompts they chose, at a concurrency they control. Our row times a public endpoint with a standard harness prompt on one day and one route.

Latency is a property of a deployed route, not an attribute of a model name. That is the same conclusion our TTFT explainer reaches from the measurement side. Quoting any one of these three as "Mercury's latency" produces a claim the other two contradict.

OpenAI's model page has the mirror-image problem. It describes GPT-Realtime 2.1 as low-latency without publishing the prompt, region, audio clip, load, and timing boundary that would make the description checkable. A claim that either model is some multiple faster than the other splices incompatible evidence.

Run the comparison from end of caller speech to first audible agent sample. Record p50, p95, interruption recovery, wrong-tool rate, and task success. Include at least one noisy clip, one partial account number, and one mid-sentence correction.

Four invoices become one without getting smaller

Mercury calls pay at least four providers or cost centers: speech recognition, Mercury 2, text-to-speech, and telephony. GPT-Realtime calls combine the first three model functions but still pay audio-token charges, telephony, tools, and any external data services.

Use one thousand replayed five-minute calls as the unit. For each system, record actual audio minutes, text and audio tokens, cached context, tool calls, retries, and abandoned turns, then price the observed trace. Vendor headline rates cannot reveal how much conversation history is resent or how often an interrupted answer is generated and discarded.

Interrupted answers deserve their own line. Callers barge in constantly. Native audio bills the output it had already started producing, and a workflow with frequent interruptions can spend a material share of its budget on speech nobody heard. Cascaded stacks waste the same work in cheaper units.

Mercury's low text price can win decisively when speech recognition and synthesis are already negotiated and efficient. GPT-Realtime can win operationally when removing two integrations reduces failures, engineering time, and delay. That saving lands in a payroll line rather than a vendor invoice, which makes it easy to leave out of the comparison and expensive to ignore.

The decision is which seams you will own

Mercury 2 fits when the team wants independent STT and TTS vendors, when text-model cost is a material part of the call bill, when structured tool output is central, when long generated answers benefit from high output rate, and when the team can operate turn detection and streaming across components.

GPT-Realtime 2.1 fits when speech nuance belongs in the model input, when interruption and silence handling must be integrated, when WebRTC, WebSocket, or SIP voice paths are preferred, when one realtime API is easier to govern than a chain, and when the organization accepts tighter provider coupling.

Our related Gemini Live comparison covers the same cascaded-versus-native decision against Google's preview model, where preview stability becomes a third variable.

Whichever way it goes, verify Mercury's first-answer time on your own route before designing a conversational turn around it. Our measurement and Inception's differ by roughly seven times, and only one of them was taken on the endpoint you would be calling.