Mercury 2 vs Gemini Live

Mercury 2 is a text model. Gemini 3.1 Flash Live Preview is a voice product wearing a preview identifier.

We will not name a latency winner. Published figures time different systems.

Mercury prices the text layer at $0.25 input and $0.75 output per million tokens. Gemini Live hears and speaks directly, if you will operate a preview model Google released on March 26, 2026.

"Gemini Live" is the product category. Google's current developer model is gemini-3.1-flash-live-preview. Preview is a deployment risk, not a footnote.

The pair is a category error

Table 1 Download CSV

Question	Mercury 2	Gemini 3.1 Flash Live Preview
Input and output	Text in, text out	Native audio plus text, image, and video input, audio output
Voice design	Cascaded STT → model → TTS	Audio-to-audio Live API
Context	128K	128K for native audio, lower limits can apply to other live modes
Tool use	Supported	Function calling supported
Structured output	Schema-aligned JSON documented	Not supported on the current model page
Search grounding	Build with an external tool	Supported, separately priced after allowance
Text price per 1M tokens	$0.25 input / $0.75 output	$0.75 input / $4.50 output
Audio price	Separate STT and TTS	$3 input / $12 output per 1M audio tokens
Stability	Hosted production API	Preview model

Google also publishes minute equivalents for audio: $0.005 per input minute and $0.018 per output minute. Those values make a first estimate easier, but accumulated context, thinking tokens, tools, and abandoned output can change the bill.

Read the first two rows before any of the others. One of these is a text model you assemble a voice product around. Its counterpart is a voice product missing the parts you would assemble. Every remaining difference follows from that.

Head-to-head number comparisons mislead more often than they help.

Mercury is cheap until the caller is waiting

Mercury 2 is a diffusion reasoning model with a 128K window, adjustable reasoning, tool use, schema-aligned JSON, and an OpenAI-compatible chat-completions endpoint. Inception lists $0.25/$0.75 per million input and output tokens.

For voice, Mercury sits between a speech recognizer and a speech generator. Teams can keep a specialist transcriber, preserve an existing voice, route regions independently, and replace Mercury later without touching the rest. They also own the seams and the latency those seams add.

Schema-aligned JSON deserves more weight than it usually gets in a voice comparison. Support workflows are mostly tool calls wearing conversation. Valid arguments from the model remove a class of failure that is expensive to handle at runtime, when the caller is already on the line and the retry is audible.

Mercury's first answer is slower than its throughput

Our runtime feed measures Mercury 2 at 3.53 seconds to first answer and 802 output tokens per second on the review date. Inception's Blackwell test reports 1,009 tokens per second. That gap is not an error. Prompt shape, hardware, load, and timing method differ, and a public endpoint under ordinary conditions is the number an application actually gets.

Throughput is genuinely excellent. First-answer time is the problem.

Cascaded voice turns spend their budget on end-of-turn detection, transcription, the model, synthesis, and transport. Handing 3.53 seconds of that budget to the model alone leaves nothing for the other four. Callers treat silence of that length as a dropped line rather than as thinking. High tokens-per-second cannot rescue it, because throughput only starts paying after the first token arrives, and the caller has already spoken again by then.

Mercury 2's price and text behavior make it attractive for a cascaded stack. Our own latency row is the strongest argument against using it for one. Both things are true. Which one governs depends on measurements from your route rather than ours.

Two ways out exist for teams that want the price. Put Mercury on the work the caller is not waiting through, such as post-call summarization, structured extraction, or a background policy check, and use a quicker model for conversational turns. Or measure your own endpoint first, because a single feed on a single day is a screen and not a verdict. Our speed dashboard carries the current row, and our TTFT explainer covers why one measurement of one route proves less than it appears to.

Gemini Live is an audio-system decision

Gemini 3.1 Flash Live Preview connects through Google's Live API and processes audio directly. Google describes it as an audio-to-audio model optimized for realtime dialogue, acoustic nuance, numeric precision, and multimodal awareness.

Google's capabilities guide lists 16 kHz native input audio and 24 kHz output audio, with resampling available. Audio-only sessions can run longer than sessions combining audio and video. Function calling is supported, and Google's current tool guide documents synchronous calls for the 3.1 model.

Native audio preserves information a transcript loses, including hesitation, pronunciation, timing, and tone. It can also accept image or video context, which matters for visual support, field work, tutoring, and any call where "what I see" belongs beside "what I hear."

That multimodal path changes evaluation. Field-support replays should include a blurry image, a camera that moves while the user speaks, a correction to a serial number, and a tool call grounded in both modalities. Score whether the cited visual detail was actually present, not only whether the response sounded confident.

Preview status is the counterweight. Model identifiers, rate limits, behavior, and availability can change before general release, so a production plan needs a pinned acceptance suite and a migration path. That path should define the replacement model, feature differences, a rollback threshold, and how active sessions drain during a change. Realtime systems make version drift immediately audible to users. Keeping model and API versions in every call trace is what lets you tie a complaint to the session that produced it.

A preview identifier is a product decision wearing a smaller font.

Unlike clocks do not produce a winner

Inception's voice report gives provider and customer figures for Mercury's reasoning and model layer. Google's Live documentation describes a low-latency endpoint but does not publish the same audio clip, region, tool call, load, and timing boundary.

Our own Mercury row has the same limitation in the other direction. It times a text completion, so it cannot be subtracted from a native audio system's turn. Nobody should read it as a voice benchmark, including our own readers.

Use one clock: end of user speech to first audible agent sample. Replay identical audio into both systems. Track p50 and p95, then record false barge-ins, missed interruptions, tool completion, transcription-sensitive errors, and task success.

One sentence should expose the difference: "No, change the delivery address to sixty-eight, not sixteen, King Street."

The cheaper token is not the cheaper call

Mercury's model-layer cost is easy to compute and incomplete by construction. Gemini's audio rates look higher per unit and cover more of the chain. Setting them side by side needs a shared denominator. One five-minute call under stated assumptions:

Table 2 Download CSV

Layer	Cascaded with Mercury 2	Gemini 3.1 Flash Live
Model or audio	About $0.027 text-model layer	About $0.061 audio, at 5 input and 2 output minutes
Speech recognition	Separate vendor charge	Included
Speech synthesis	Separate vendor charge	Included
Search grounding	Build and pay for a tool	Billable after the monthly allowance
Total	Model layer plus two speech bills	Roughly the audio line, plus text and thinking

Those figures are an illustration, not a quote. Mercury's line reuses the token assumptions from our customer-service guide. Gemini's line applies Google's published minute equivalents to one call shape. We have not benchmarked speech-vendor pricing, which is the term that decides the comparison. Teams with a cheap recognizer and an existing voice contract land in a very different place from teams buying both new.

Google's Live API guidance adds a wrinkle worth pricing before commitment: accumulated session context can be processed again as a conversation grows, thinking tokens are included in output pricing, and search grounding can generate billable queries after the allowance. Long calls are therefore superlinear rather than linear. Five-minute averages hide the twenty-minute call that costs six times the median.

Capture real usage traces from the same replay set. Theoretical five-minute calls with continuous audio differ sharply from a call with long silence, interruptions, and one expensive search tool.

Operate the failure you can name

Mercury fits teams that want independent speech vendors, very low text-token prices, an OpenAI-compatible text endpoint, schema-aligned tool output, and control over component-level routing. It asks the team to integrate more and, on our current measurement, to solve a first-answer problem before it reaches a caller.

Gemini 3.1 Flash Live Preview fits teams that want native acoustic context, audio-to-audio generation, image or video in the live session, Search grounding, and fewer model boundaries in the conversational path. It asks the team to tolerate platform coupling and preview risk in exchange for a shorter chain.

Neither pick survives a provider update.

Own the replay set. That opinion expires the next time Google changes the preview id, or the next time a public Mercury endpoint answers in under a second.