Google makes Gemini Computer Use generally available across two APIs Google makes Gemini Computer Use generally available across two APIs

The application runs the actions

The Computer Use guide describes a screenshot-driven loop: the model proposes an action, the client executes it, then returns the resulting screen. Browser, mobile and desktop environments have distinct action sets. Mobile actions are Android-optimized. Responses can include an intent and a safety decision; the client is responsible for obtaining user confirmation before execution. The separation is practical: selecting the tool in a request does not supply the browser driver, device connection or desktop session that carries out the work.

Google’s documented screenshot injection detector is opt-in and defaults to false. Policy overrides also do not eliminate the need to process confirmation responses. These are integration requirements in the current guide, not a list of features first introduced by the October 30 announcement. The release note establishes the change in availability. For an application already using Gemini, that is a different change from replacing its model or rewriting its entire orchestration layer.

Stored history does not preserve every setting

The Interactions API can continue a conversation through previous_interaction_id instead of requiring the application to resend its history. That identifier preserves inputs and outputs, but tools, system instructions and generation configuration remain specific to each request. They must be supplied again when needed. The API also exposes a sequence of execution steps, including tool calls, results and model output. This gives the application more than a final text answer to process. In a multi-turn interface, conversation continuity and configuration continuity are therefore separate responsibilities.

The Interactions documentation lists storage as enabled by default, with retention of 55 days on the paid tier and one day on the free tier. Setting store=false prevents later chaining through the interaction identifier and is incompatible with background execution. Paid projects can select shorter retention windows. The same documentation calls GenerateContent fully supported, while recommending Interactions for new projects. It also lists feature differences: explicit caching and Python automatic function calling remain available through GenerateContent but not Interactions. Choosing an interface therefore involves existing application dependencies as well as access to this tool.

An earlier storage change also matters

A separate October 26 release changed GenerateContent storage defaults for new paid-tier projects. Those projects store requests by default; existing projects retain their previous setting. Developers can opt out per request or through logging settings. That earlier change is relevant when comparing the two routes, but it is not part of the Computer Use launch. Together, the documented choices separate three concerns: obtaining a proposed action, deciding whether to execute it, and retaining the conversation that produced it. General availability does not combine those responsibilities into a hosted desktop service.