Gemini in 2025: From Thinking Budgets to Real-Time Voice

Control how much the model thinks

Does every request need Gemini to spend time reasoning? Thinking budgets let developers control that work. Gemini 2.5 Flash already supported them; for Gemini 2.5 Pro, budgets and an option to disable thinking were expected alongside the general-availability release within weeks, hopefully in early June 2025. These were release expectations at the time of the Google I/O conversation.

Thought summaries addressed a related question: how much of the model’s thinking should developers see? Summaries were already live, with a participant reporting their appearance in Cursor. The team was seeking feedback on where summaries sufficed and where developers needed more detail. Shrestha framed both budgets and summaries as ways to give developers more control over thinking models.

Shrestha’s personal highlight was native audio output that could switch between Bengali and English, matching how she speaks. She also cited a Matt Veloso demo involving Klingon, an unofficially supported behavior. Her other pick, URL Context, retrieves deeper information from web pages, either alone or paired with search, to support applications such as developer-built research agents.

Caching saves cost; faster generation could change interfaces

Repeated chats over the same material offer a straightforward reason to cache context—retain material for reuse. Gemini offered two approaches: - Implicit caching automatically passes savings to developers without requiring cache management. - Explicit caching lets developers ensure that particular material is cached for repeated use. No savings rate or cache-hit conditions were specified for implicit caching. Retention also has infrastructure costs, and caching improves latency only in some cases.

Gemini Diffusion prompted a more speculative application: generative user interfaces, built during interaction rather than predefined as a website. Each click could trigger roughly a thousand tokens of code to construct the next interface. Faster generation could make that interaction practical where waiting for tokens currently made it awkward.

This was a proposed use case, not a demonstrated result. Gemini Diffusion still needed substantial work on production readiness and quality before meeting the team’s bar for broader release.

Keep a live session useful as it grows

The Gemini Live API supports live audio and video interactions. Shrestha said transcription had been one of its largest use cases before native audio output arrived; the newer capability interleaved text and audio output. Production users also needed longer sessions. The initial video-session limit was about five minutes, prompting controls for a sliding context window, which manages the context retained as a session progresses, and configurable video resolution.

Tool use added another requirement. The API could chain search and code execution for analysis, but function calling and search performance remained areas of continuing improvement. Integrating a live API also demanded a larger commitment than using a text-generation API: providers’ bespoke infrastructure made switching difficult. Model-agnostic infrastructure was a hoped-for way to reduce that cost.

Long sessions can also change the agent’s task. Shrestha described gaming agents with multiple states, customer-support interactions that could last hours, and screen-sharing assistance. A Shopify demo at Next showed setup of Domain Name System (DNS) settings using Cloudflare. Moving between workflow states or handing a session to another agent can require changing system instructions mid-workflow; support for these transitions was still developing.

Develop capabilities separately, then bring them together

Voice applications faced an architectural choice: assemble separate speech and language components, or use an audio-to-audio model that accepts and produces audio. Shrestha expected many applications might eventually migrate to audio-to-audio as those models improved, while emphasizing developers’ continued interest in separate components. Google had released two controllable, promptable text-to-speech (TTS) models at I/O; those models were not yet available through the Live API.

Gemini’s stated direction was one mainline model, with specialized branches used to develop and harden capabilities before reintegration. Reasoning illustrated the approach: separate research models let teams improve reasoning without initially having to protect every multimodal capability. Combining the work could introduce tensions, but also benefits across capabilities.

A participant attributed Gemini 2.5 Pro’s improved video understanding to integrated reasoning rather than targeted video work, calling the result state of the art without naming a benchmark or evaluation conditions. Image generation showed why specialization persisted: Gemini supported interleaved text and images, while developers still used a separate image-model family for generation, editing and high-quality photorealistic work. Bringing those capabilities into Gemini remained ongoing work.

Voice architecture balances quality, cost and latency

Pipecat supplies another layer: an open-source framework for voice orchestration, introduced as supporting all Gemini models. Shrestha described Daily as a partner since the Live API’s launch, with its feedback influencing development, and named LiveKit as another partner. The accompanying World’s Fair preview announced a Gemini Live API and Pipecat workshop with Shrestha and Kwindla.

The original Live API used a cascaded architecture: native audio input combined with a separate text-to-speech output stage. Shrestha explained that the TTS models powering NotebookLM helped meet the desired quality and latency targets. That architecture remained available alongside the newly released audio-to-audio architecture. Native audio output models were available only through the Live API.

These choices balanced latency, cost and output quality, with multilingual support adding another consideration. Developers had requested better German support; Shrestha hoped the new models addressed that need, without offering measured language-quality results.

Voice activity detection identifies speech activity in incoming audio. The Live API exposed controls for detector sensitivity and audio padding around speech boundaries, and developers could disable the built-in detector and supply their own. Shrestha described combining the components while keeping latency around 500–700 milliseconds as one of the API’s hardest challenges. That range was a target, not a measured latency distribution.

Frameworks address additional problems such as turn detection—deciding when a conversational turn ends—and context management. As solutions mature, some move into APIs or models; broader applications then create new framework work. Beneath both sits low-latency packet transport: audio and video still have to cross the internet. One participant argued that users expect roughly half-second conversational responses and bring that expectation to AI, making inference speed only one part of the timing problem.

Know when to stay silent and when to keep working

Suppose someone talking with an AI turns aside to answer another person. The useful response may be silence. Proactive audio, an experimental feature available only in the native audio-to-audio architecture, was trained to avoid responding to irrelevant audio cues. It was described as directionally similar to semantic voice activity detection: whether the AI should participate depends on the meaning and context of speech. Another participant recalled a demo in which the AI appeared to ignore a background question.

A separate observation was that a model could distinguish two people by their voices. A participant reported experimenting with this behavior, but the response explicitly clarified that it was not officially supported. The observed capability was not a product guarantee for speaker identification.

Asynchronous function calling addressed a different source of delay. It had launched for the cascaded architecture: a non-blocking parameter allowed a function to execute in the background instead of requiring a wait for its response. Bringing this capability to native audio was still an aspiration. Architecture choice therefore affected tool behavior as well as speech output.

The wish list: more languages, more capabilities in one model

The closing wish list returned to the people building voice applications worldwide. More language support was the voice-infrastructure participant’s priority. Shrestha said the model officially supported 24 languages, distinguishing that coverage from its reported ability to respond in Klingon. She was optimistic about expanding language capabilities before the next I/O, without making a concrete release commitment.

Shrestha’s broader wish was to bring more capabilities into the main model. For developers, that ambition coexisted with practical choices still available—and necessary—outside it: separate speech components, configurable voice detection, framework-managed context and architecture-specific tool execution.