Mercury 2 vs GPT-Realtime 2.1

Choose Mercury 2 for a low-cost cascaded voice stack. Choose GPT-Realtime 2.1 when the application needs native speech-to-speech, acoustic context, and integrated interruption handling. We do not declare a latency winner from their published numbers: Mercury's measurements time text generation, while GPT-Realtime operates on audio.

The requested URL uses “GPT-4o Realtime” because that is the older product name people search. OpenAI's current model catalog has moved on. The implementation choice in August 2026 is GPT-Realtime 2.1.

The architecture boundary, not the old product name, is the useful comparison.

The architecture decides the comparison

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 and transport-oriented API surface. The right comparison is therefore system against system, not one token-rate cell against another.

Mercury 2 keeps the stack 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 per million input tokens and $0.75 per million output tokens.

The current hosted runtime row measures 802 output tokens per second and 3.53 seconds to the first answer. Inception separately reports 1,009 tokens per second on NVIDIA Blackwell. These are different workloads, the independent row is the one used for cross-provider screening.

The attraction is control. A team can choose its speech recognizer, voices, regional deployment, interruption detector, and telephony provider. It can also swap the text model without rebuilding the audio layer.

That freedom creates more boundaries. The system 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.

It also creates a clearer audit trail. The application can retain the transcript, exact Mercury request, tool arguments, returned text, and synthesized audio identifiers as separate events. That separation helps diagnose whether a bad call began with recognition, reasoning, a tool, or pronunciation. The benefit appears only if one trace links every component.

GPT-Realtime 2.1 hears the conversation

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 can discard: hesitation, tone, pacing, pronunciation, and overlapping speech. It also reduces the number of vendors in the conversational path. The trade is coupling. Model, voice behavior, audio billing, and realtime API semantics come from the same provider.

Operational testing should include session reconnects, audio cancellation, tool results that arrive after the caller changes the request, and calls that cross the context limit. Native audio removes component calls, it does not remove state management.

Why the latency claims do not line up

Inception's voice-agent report discusses a roughly 300 ms reasoning trace and customer-observed model latency below about 500 ms. The current hosted row times Mercury 2 at 3.53 seconds to first answer. Neither number includes a standardized speech recognizer, voice, network, and telephony path shared with GPT-Realtime 2.1.

OpenAI's model page describes GPT-Realtime 2.1 as low-latency but does not publish the same prompt, region, audio clip, load, and timing boundary. A claim that one model is “8× faster” would splice incompatible evidence together.

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.

The cost boundary matters

A Mercury call pays at least four providers or cost centers: speech recognition, Mercury 2, text-to-speech, and telephony. A GPT-Realtime call combines the first three model functions but still pays 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 discarded.

Mercury's low text price can win decisively when STT and TTS are already negotiated and efficient. GPT-Realtime can win operationally when removing two integrations reduces failures, engineering work, and delay.

Choose by what you want to own

Choose Mercury 2 when:

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

Choose GPT-Realtime 2.1 when:

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

The sharper question is not which model wins. It is whether the team wants to own the seams.