The arrival of Gemini 3.1 Flash Live This has completely changed the conversation about voice and real-time AI. We're no longer just talking about text-to-speech, but about agents capable of listening, reasoning, calling tools, searching the web, and responding in natural voice within a single live session. And all of this with a pricing structure that, for the first time, allows us to consider serious voice products without the cost skyrocketing.
Meanwhile, Google has made its move with Gemini 3.1 Flash-Lite and the rest of the 3.1 familyThis completes a tiered model architecture that affects both how we design our systems and how much we pay for each conversation. If you're thinking about migrating from Gemini 2.5 Flash Live, launching a phone assistant, or setting up large-scale moderation and support pipelines, it's essential to fully understand what each component offers… and where the subtle nuances lie that can later become costly bugs.
What exactly is Gemini 3.1 Flash Live?
Gemini 3.1 Flash Live It's Google's latest real-time audio model, available in preview through Gemini Live API within Google AI Studio and Vertex AI. The model's technical identifier is gemini-3.1-flash-live-preview, and is designed as a native audio model optimized for low-latency dialogues with acoustic nuances, numerical accuracy and multimodal understanding (text, image, audio and video).
It is important to understand that there is no separate product called “Gemini 3.1 Flash Live API”What there is is Gemini Live API as a common surface, on which you can run different Live models (including this 3.1 Flash Live). Technically, it is a WebSocket session with status, designed for continuous streaming, user interruptions, multimodal input and spoken responses, not for a simple classic request-response cycle like generateContent.
Official documentation indicates that the model supports function calling y Search groundingIn practical terms: it's not just a pretty TTS system, but a voice agent capable of Use external tools and consult the web during the conversation itself. The model's information sheet indicates a knowledge cutoff in January 2025So if your use case needs up-to-date information, you'll have to rely on grounding, your own retrieval system, or integration with other APIs.
There are two technical details that are easy to overlook. On the one hand, the model's specifications mention that text and audio outputHowever, the Live API capabilities guide emphasizes that native audio models work with response modality AUDIOThe prudent approach for production is to treat the text as a layer of output transcriptThis is not a guarantee that you will always receive a purely text-based response. On the other hand, Google confirms that all audio generated by Gemini 3.1 Flash Live is brand with SynthIDThis is relevant if your application is aimed at end users and you have to report on synthetic content.
Real-world production experience: more natural voice and simplified pipeline
One of the most striking changes when switching to Gemini 3.1 Flash Live Teams already operating voice agents in production are noticing this. A clear example is the open-source platform DograhDesigned to build call center agents with a visual workflow builder. Previously, they used the typical combination of STT + LLM + TTS (for example, Deepgram/Gladia for transcription, an independent LLM for reasoning, and ElevenLabs or Cartesia for speech synthesis).
That approach involved three chained API jumps, with the resulting complexity and cost. When migrating to Gemini 3.1 Flash Live, that entire pipeline collapses. a single Live connectionIn practice, the team reports a clear improvement in the perceived voice quality and conversation paceIt's not just "a slightly better TTS": the model handles pauses, user interruptions, and overall tempo more naturally, making the interaction sound closer to talking to a real person.
Regarding latency, their tests from Asia (against servers in the United States) yield an average of around 922 ms per response. It's a slightly higher figure than the sub-300 ms claims circulating in some demos, but quite reasonable considering the transcontinental network component. The obvious hypothesis is that in the United States or regions closer to the server You can achieve significantly better times, so if you're developing from Europe or America, it's advisable to measure with your own numbers.
There is a point of contention that has surprised them: Real-time transcripts are not accessible during the callThey are available once the session has ended, which is perfect for post-call analysis, but makes it much more difficult to... live context engineeringIf your agent needs, for example, to summarize what has already been discussed mid-conversation, you need to rethink how you manage context and what information you keep in your own backend instead of relying on a continuous transcript provided by the model.
On the economic side, the pricing structure of Gemini 3.1 Flash Live turns out competitive versus operating three separate APIs (STT, LLM, TTS). Furthermore, the ability to calling tools during live audio sessions It works reliably. For many developments, we reach a point where the old STT + LLM + TTS architecture starts to feel like the wrong approach, both in terms of cost and added robustness and latency.
The Gemini 3.1 family: Pro, Flash and Flash-Lite
Gemini 3.1 is not limited to Live; Google has articulated a family of tiered models with well-defined roles. At the top is Gemini 3.1 Prodesigned for complex reasoning and demanding tasks. At the midpoint we find Gemini 3.1 Flashwhich aims to combine good reasoning skills with speed. And it falls into the volume and affordable price category. Gemini 3.1 Flash-Lite, the most cost-effective model for repetitive workloads and low latency.
What's interesting about Flash Lite is that it's not just a stripped-down version of Flash. It's built on the same basic architecture as Gemini 3 ProBut it's specifically tuned to prioritize performance and cost. That's why it performs better than expected in many benchmarks for its price, even matching or surpassing the capabilities of other processors. Gemini 2.5 Flash despite being faster and cheaper.
Flash-Lite and its “levels of thought” logic
The most striking conceptual innovation of Gemini 3.1 Flash-Lite It is the introduction of the so-called levels of thoughtMinimum, low, medium, and high. We're not talking about a change in model, but rather how much internal computing power is allocated to each task. For a simple text translation, for example, you can set the level to minimum and achieve a virtually instant and very cheap responseIf the task demands more precision or requires interpreting nuances, you raise the level to medium or high and accept a spike in latency and cost.
In tests with customer support ticketsAt the lowest level, responses arrived in less than two seconds, sufficient for routine questions. At the medium level, it took about five seconds, but it better captured the details hidden in the message, which can be key when user satisfaction is at stake. This ability to modulate the “thinking” of the model Depending on the task and budget, it is a very powerful tool to adapt to the requirements of each product.
Cost and performance of Gemini 3.1 Flash-Lite
In terms of price, Flash-Lite is positioned as the most economical model in the Gemini lineThe advertised rate is around $0,25 per million input tokens y $1,50 per million output tokensIn contrast, Gemini 3.1 Pro starts at around $2 per million tokens entering and $18 per million tokens exiting under heavy loads, so we're talking about approximately one eighth of the cost for basic tasks.
The striking thing is that It is also cheaper than the Gemini 2.5 Flashwhich was around $0,30/$2,50, despite offering greater capacity. This is an unusual move, because normally an improvement in features translates into an equal or higher price. In terms of performance, Google speaks of a generation speed of approximately 363 tokens per secondwith a time to the first token about 2,5 times faster than in 2.5 Flash. In content moderation or classification pipelines, that difference between a three-second wait and one second is very noticeable when processing hundreds or thousands of items.
Flash-Lite supports multimodal input (text, images, audio and video), with a context window of up to 1 million tokens and the ability to generate up to 64.000 text output tokens. In real-world tests with e-commerce catalogs and image tagging, a very high level of consistency in classificationThis is critical when you automate product labeling or community moderation on a large scale.
When to use Flash-Lite and when to upgrade to Flash or Pro
The simple operating rule would be: Use Gemini 3.1 Flash-Lite when you run thousands or millions of homogeneous tasks where the cost per token matters more than advanced reasoning. Let's consider mass translation, content moderation, simple sentiment analysis, or structured data extraction (for example, key fields of invoices and receipts).
A very effective pattern is to use Flash-Lite as routing modelIt is tasked with reading the incoming request, classifying it as "simple" or "complex," and, based on that, redirecting the job to Flash or Pro. This approach allows reduce overall cost without sacrificing quality in the tasks that truly require a more powerful model. In fact, the very Open source Gemini CLI It already uses Flash-Lite for this traffic controller role.
On the other hand, if the task involves Multi-step reasoning, creativity, solving ambiguous problems, or complex programmingIt's best to go directly to Gemini 3.1 Flash or ProIn a test to generate user interface components from natural language descriptions, Flash-Lite performed well with very direct requests, but fell short when the prompt was vaguer or required open-ended design decisions. Gemini 3.1 Flash handled both precise and more open-ended requests with much more robust results.
What did Google actually launch on March 26th and what is the current status of the model?
The official announcement of March 26th 2026 presents Gemini 3.1 Flash Live as the latest model of real-time audio from Google, available to developers at preview modeThe template page embodies that marketing message in a technical contract: gemini-3.1-flash-live-preview code, multimodal input, and clear orientation to low-latency dialogue.
In the documentation notes, Google makes it clear that this model supports function calling and grounding with Searchand which continues to actively evolve, with constant improvements in instruction following, audio input quality, and reasoning capabilities. At launch and in the months that followed, the model continued to be marketed as preview...with the correspondingly more conservative rate limits. For regular tests, the fees don't usually trigger, but if you're planning a industrial deployment in productionIt is key to check your specific limits in AI Studio instead of assuming what you read in a generic table.
Choose between Gemini 2.5 Flash Live and 3.1 Flash Live
For new projects, the logical recommendation is to start directly with Gemini 3.1 Flash LiveGoogle identifies it as its benchmark Live model, and furthermore, the migration documentation itself indicates that it expects a gradual move from gemini-2.5-flash-native-audio-preview-12-2025However, migrating does not mean that "everything from 2.5 exists equally or better in 3.1".
The key is to check if your current design depends on capabilities that 2.5 does offer and 3.1 does not yet replicateThe migration guide is very clear: Gemini 3.1 Flash Live use sequential tool callingIf you were exploiting `behavior: NON_BLOCKING` in 2.5 to keep the conversation going while the tools worked in the background, that pattern is no longer available in 3.1. The same applies to features like proactive audio or affective dialogueIf your UX relied on those behaviors for some of its magic, you could lose more than you gain just by improving voice quality.
An honest summary would be something like this: if you start a project, use 3.1 Flash LiveIf you already have a mature system running Flash Live 2.5, Migrate only when the new restrictions are a good fit for your product.Sometimes, a cleaner architecture and slightly better latency don't compensate for the loss of certain asynchronous capabilities that your current experience takes for granted.
Gemini 3.1 Flash Live prices read as an operator, not as tokens
One of the strengths of Live's new pricing structure is that includes per-minute ratesmuch closer to how someone operating a voice product thinks than figures in millions of tokens. Assuming continuous input and output audio, the published numbers imply around $0.023 per minute of purely audio conversation. A 10-minute call would cost around $0.23 of the gross cost of the model before adding grounding, image or video processing and the rest of your infrastructure.
The grounding with Google Search This is another cost line that many underestimate. With an approximate rate of $14 per 1.000 consultationsEach call to Search costs around $0.014 once the free tier is exceeded. A voice session triggering five queries would add around $0.07 extraIt doesn't seem dramatic in an isolated call, but in high-volume products it ends up affecting the margin.
There is an additional, less obvious risk in video. The migration guide explains that, by default, the Turn coverage includes all video framesIf you're coming from version 2.5 and are used to sending video with the camera open all the time while the actual work is almost all voice-based, in version 3.1 you might find yourself with a silently inflated billAnd, as always with preview models, the quotas for requests per minute or per day don't appear clearly on the public page; you have to go to Use Google AI Studio to check the actual rate limits of your project.
Integration architecture: backend first, browser later
If you're looking for something functional with Gemini 3.1 Flash Live as soon as possibleThe fastest and most sensible path remains integration server-to-serverThe Live API documentation treats it practically as the default option. The basic pattern is clear: you open a Live session, indicate that you want AUDIO response and you start sending data through send_realtime_input as audio, text, or video arrive from your application.
For real audio, Google requires 16-bit 16 kHz little-endian PCM as input, with a MIME type of the style audio/pcm;rate=16000. The output audio is PCM at 24 kHz. The documented session limits are 15 minutes for audio-only sessions y 2 minutes if there is audio + videoalthough they can be logically expanded by applying the techniques of session management and summary described in the guide.
If you need a direct connection from the browser, Google does not recommend exposing a long API key on the frontend, but rather working with ephemeral tokensThe idea is simple: you issue short-lived tokens from your backend, the client uses them like an API key to open the Live session, and you improve end-to-end latency without compromising security. Typical defaults are around 1 minute to open a new session with the token and then about 30 minutes to continue sending messages on that connection, as long as the token makes operational sense.
Typical errors when migrating from Gemini 2.5 Flash Live to 3.1 Flash Live
The most treacherous part of a migration is not the noisy failures, but what It continues to function “only partially” While your application is already behaving differently than expected, the 3.1 documentation highlights a number of changes that should be applied carefully to avoid wasting hours debugging.
First of all, you have to Stop sending thinkingBudgetIn version 3.1 that configuration no longer exists and the control is renamed thinkingLevelwith a default value of minimal to prioritize latency. If you continue using the old parameter of 2.5, you're just turning a knob that does nothing. Secondly, when processing server events, it is fundamental Read all parts of each eventBecause a single message can include both audio and transcription; if your parser assumes one part per event, you can lose data without realizing it.
The client message flow also changes. In 2.5, send_client_content could continue to fuel the conversation throughout the session; in 3.1 it is left for the initial seedEverything that happens live must go through send_realtime_inputAs for tools, they must be designed as blocking and synchronousThe model waits for the tool's response before proceeding. If your experience relied on background tools while the conversation continued, you'll need to redesign the orchestration.
Other recommended settings are Remove unsupported options from the settings such as proactive audio or affective dialogue, carefully review the video submission to avoid paying for unnecessary frames, and if you need text, always treat it as an output transcriptThe documentation is somewhat ambiguous on that point, so assuming you will always have "clean" text as if it were a purely textual model can lead to surprises.
When is Gemini 3.1 Flash Live not the right choice?
Despite its advantages, there are many situations where choosing another piece of the ecosystem makes more sense. If your product It doesn't revolve around real-time voice.The Live API adds unnecessary complexity: WebSocket session management, PCM audio, interrupts, ephemeral tokens, etc. For classic text chat or content generation, you're probably better off with non-Live models from the Gemini family.
If your current system relies heavily on asynchronous use of toolsMigrating to 3.1 might even worsen the experience. This is the main reason to stick with Flash Live 2.5 for a while longer. Similarly, if you can't implement a backend layer capable of broadcasting ephemeral tokens with securityDon't force a direct browser architecture: keeping the entire Live session on the server side remains the most sensible alternative.
And if all you need is convert text to speech Without reasoning, tools, or multimodality, a pure TTS service will almost certainly be simpler and cheaper to operateThe Gemini 3.1 Flash Live is designed for complex conversational agents; using it as a simple smart speaker is often like using a cannon to kill flies.
Taken together, the arrival of Gemini 3.1 Flash Live and Flash-Lite marks a turning point: on the one hand, they simplify the classic STT + LLM + TTS stack into a single layer capable of maintaining rich conversations with tools and grounding; on the other hand, they consolidate a layered AI infrastructure model in which you combine a cheap and fast router with powerful reasoners when required.
Understanding its limitations—real latency, cost per minute, restrictions on tool usage and video handling—is what will allow you to move from flashy tests to voice products that hold up in production and scale without throwing your margins out the window. Share the information so that more users can learn about the topic.