The Gemini Interactions API

Google’s new Gemini Interactions API reframes how developers build with Gemini models by shifting from simple, stateless “prompt in, text out” calls toward agent-ready, multimodal, tool-using workflows—while also adding optional server-side conversation state to cut token costs.

The API’s design reflects how LLM usage has changed since early completions endpoints. Back then, developers sent a prompt and received a completion with no built-in conversation memory. Chat-style APIs later introduced roles (system, user, assistant) to better manage context, still largely stateless but more structured. Function calling then forced additional API changes as models began triggering external actions. By 2025, the center of gravity has moved again: “agents” now run multi-step loops, call tools, execute code, and often coordinate multiple model calls—meaning the old conversational scaffolding is no longer enough.

Gemini Interactions API targets that agent reality directly. One of its first upgrades is optional server-side history. Instead of resending the entire conversation every time, developers can reference a prior interaction ID to persist context on Google’s side. That persistence enables implicit caching for long prompts, improving token efficiency and reducing cost during multi-turn interactions. The transcript demonstrates this with a multi-turn exchange where the model remembers a user’s name across turns, and then shows token usage rising more slowly once prompts exceed roughly a thousand tokens—consistent with backend caching behavior.

The API also expands beyond “model calls” into “agent calls.” Developers can invoke Gemini research agents—specifically the Gemini deep research pro preview agent (December 2025). The agent runs server-side, supports background execution for long-running tasks, and returns an interaction ID immediately. Clients can poll for completion or failure and then fetch the final output once the agent finishes. In the example, the deep research agent produces a structured markdown history of Jax and includes citations, illustrating the agent’s ability to do multi-step research work.

Multimodality is treated as both input and output. On the input side, the API accepts images, audio, video, and PDFs either via file handling or by base64-encoding content. On the output side, developers can request generated artifacts such as images (and similarly audio/video) by specifying response modalities. The transcript highlights an image-generation example using the Nano Banana Pro model.

For structured outputs, the API leans into schema-first responses using Pydantic model definitions and JSON schema validation, making it easier to reliably parse model outputs into typed data structures.

Finally, the interactions API unifies tool use. It supports standard function calling patterns, built-in tools like Google Search, code execution, and URL context retrieval, plus remote MCP servers for integrating external services (e.g., a weather MCP). Background execution, server-side state, and tool orchestration together position the API as a foundation for more complex agent systems—such as “computer use” agents—built to run in sandboxes and handle multi-step tasks without keeping a client connection open.