Google’s general-availability announcement for Computer Use changes the tool’s status, not the division between a model’s suggestion and an executed action. The model receives a screen image and proposes a UI operation; the client application executes the operation in a target environment and sends back the next screen. For builders, the model response is a proposal, not a completed interaction.
The October 30, 2026, Gemini API changelog says Google released Computer Use to general availability across the Interactions and GenerateContent APIs. It describes a model tool for browser, mobile and desktop interaction, but the documentation spells out what implementation requires. The tool processes screenshots and suggests clicks, scrolls or keystrokes; the client remains the component that executes them and returns screen state.
The documented loop begins when an application sends a request, configuration, prompt and screenshot to the model. The model analyzes the screen and returns a suggested function call, such as a click, scroll or key press. The client parses the call and executes it in the target environment. It then captures the changed screen and returns that view to the model for another step. The Computer Use documentation sets out this loop.
That distinction determines what a builder must implement. A function call is a model output describing an action; the application must parse it, translate its parameters, execute it and report the new screen. The next screenshot supplies the visual state for the following turn. The work therefore sits partly in the model call and partly in the client’s execution code.
One implementation detail shows why the client is not a passive wrapper. The model’s coordinates are normalized to a reference screen scale; client code has to map them to the actual viewport before executing a click. Google’s examples use automation tools such as Playwright for those actions. The client translates the call, performs it and captures the next state, so the model’s next suggestion is based on the screen after the previous action.
Google describes browser, mobile and desktop environments for Computer Use and lists tasks such as filling forms, testing web applications and researching product information across websites. These are documented use cases, not evidence of adoption or independent testing. For builders, the implementation question is whether the client can carry the proposed action into the chosen environment and return a useful next screenshot. Google recommends a sandboxed virtual machine or container to isolate the execution environment from the host; this is a recommendation, not proof that every implementation is automatically isolated.
The response may carry information that helps a client decide how to handle an action. For Gemini 4 and Gemini 3.x models, Google says an intent field can explain why the model selected an action. A safety decision may classify an action as allowed, requiring confirmation or blocked. Google’s guidance says the client should halt execution or handle an interruption when an action is blocked. The application still needs to implement this response path.
Prompt-injection detection is opt-in, rather than active by default. Google’s guide shows the setting disabled unless a developer enables it, and describes detection as scanning screenshots for hidden adversarial instructions. That matters when a model is asked to read interface content as well as act on it: indirect prompt injection is a documented security concept, not evidence that an attack occurred in any particular deployment.
The same documentation warns that Computer Use may contain errors and security vulnerabilities. Google recommends close supervision for important tasks and advises against using it for critical decisions, sensitive data or actions where serious errors cannot be corrected. These are limits on the situations Google recommends, not proof that every use will fail. The application’s suitability depends on what it is allowed to do and how reversible the action is.
General availability makes the tool available through two APIs, but does not eliminate the application layer between a model proposal and a changed screen. Builders still need the action handler, execution environment, screenshot loop and safety-decision behavior described in Google’s guide. The release establishes availability, not performance, adoption or workflow reliability.
