What changed
Google's October 30, 2026 Gemini API release notes mark the Computer Use tool generally available in both Interactions and GenerateContent APIs. The tool was previously in public preview, including a June 24 preview release for Gemini 3.5 Flash. Google's current guide documents screenshot-based browser, mobile and desktop action planning, structured action intents for Gemini 3.x/4 models, built-in safety decisions, optional screenshot prompt-injection detection and sample client-side execution loops. GA is a platform support milestone; it does not turn the tool into a Google-hosted browser, desktop or mobile executor.
Why it matters
Developers can now plan production integrations against a generally available tool surface instead of a preview, while retaining responsibility for the dangerous part: actually executing model-suggested UI actions. A model's function call is a proposal, not an authorised action. Applications must maintain a controlled environment, action allowlists, user approvals, telemetry and rollback strategies. This matters for test automation, repetitive back-office work and assisted browsing, but does not establish improved agent success rates or eliminate prompt-injection risk.
What became generally available
The Gemini API changelog dated October 30 says Computer Use is GA across the Interactions API and the GenerateContent API. Google's guide supports browser, mobile and desktop environments and gives Python, JavaScript, Java and Go integration examples. The model consumes screenshots, proposes UI actions and, for newer models, supplies an intent field describing the action. This GA announcement follows earlier previews; it is not the first release of Gemini computer use.
The client, not Google, runs the mouse and keyboard
An application sends the task, environment configuration and screenshot to Gemini; the model returns a function_call such as click, scroll or type, optionally with a safety_decision. The application's own handler maps coordinates to the viewport, executes the action with a tool such as Playwright, captures a new screenshot and feeds the result back to the API. Developers must build or host the browser/mobile/desktop environment, handle failures and maintain the loop. Google's reference implementation uses a sandboxed Docker environment as a starting point.
Safety decisions and prompt injection are not automatic guarantees
The tool exposes safety categories covering financial transactions, sensitive data modification, communication, account creation, data deletion, consent and legal agreements. Actions may be allowed, blocked or marked require_confirmation. Even when developers override some policy categories, Google warns that confirmation may still be required; the client must implement that handling. Screenshot prompt-injection scanning is opt-in and disabled by default. Google's guidance recommends human review for consequential tasks, environment isolation, allowlists, logs and avoiding irreversible high-stakes actions.
Practical implementation checks
Choose a supported model, use the documented computer_use tool configuration for the intended environment and build a bounded screenshot/action loop. Log model suggestions, actual executed actions, safety outcomes and screen state with appropriate privacy controls. Treat third-party pages and displayed instructions as untrusted. Require human approval before sending communications, making purchases, changing sensitive records or accepting legal terms. Test recovery from failed clicks, changed page layouts, expired sessions and malicious UI content.