Gemini API makes Computer Use generally available for the Interactions and GenerateContent APIs
Google has made Computer Use generally available in the Gemini API. The October 30, 2026 entry in the official Gemini API release notes states that Computer Use is now generally available for both the Interactions API and the GenerateContent API, the two ways developers call Gemini models directly. The capability lets a model look at a screenshot of a browser, a desktop or an Android device, decide on the next action, and return that action as a structured function call that the developer's own code then executes.
The general availability entry is short, and the substance sits in the Computer Use documentation that accompanies it. According to that documentation, four models currently support the tool: Gemini 4 Argon (`gemini-4-argon`), Gemini 3.8 Flash (`gemini-3.8-flash`), Gemini 3.5 Flash-Lite (`gemini-3.5-flash-lite`) and Gemini 3 Flash Preview (`gemini-3-flash-preview`). Google describes Gemini 3.8 Flash as the recommended model for computer use, Gemini 4 Argon as the most capable option for complex reasoning and agentic UI workflows, and Gemini 3.5 Flash-Lite as the low-latency, cost-effective choice. The tool supports three environments, browser, mobile and desktop, and it is billed through the ordinary token prices of whichever model is used, since the pricing page lists no separate Computer Use fee.
The move closes a path that began with a standalone Gemini 2.5 computer use model and continued in June 2026, when Google turned computer use into a built-in tool of Gemini 3.5 Flash. For teams that had been treating the feature as an experiment, the practical change is that a capability documented for production use is now offered across the main Gemini model lineup, through both APIs, with a defined safety layer that applications are expected to handle.
··········
WHAT GENERAL AVAILABILITY COVERS IN THE GEMINI API.
The release note is precise about scope: Computer Use is generally available for the Interactions API and for the GenerateContent API. The Interactions API is the newer, stateful interface in which follow-up turns reference a previous interaction through `previous_interaction_id`, so the server keeps the conversation state between steps of an agent loop. GenerateContent is the established request-response API that most existing Gemini integrations use, and which Google's documentation now labels as legacy. Supporting both matters for adoption, because teams with existing GenerateContent pipelines can add Computer Use without migrating, while new projects can build on the Interactions API's state handling.
One detail deserves attention. At the time of writing, the Computer Use documentation still carries the sentence "As a Preview capability, Computer Use may contain errors and security vulnerabilities." The release note announces general availability, while the page that describes the feature has not yet dropped the preview wording. The more useful reading of that sentence is not the label but the advice attached to it: Google recommends close supervision and warns against using the tool for critical decisions, sensitive data or actions where serious errors cannot be corrected. General availability changes the support status of the API surface; it does not make an autonomous agent clicking through a live interface free of risk, and Google's own documentation does not claim that it does.
The table below summarizes the models that the documentation lists for Computer Use and the role Google assigns to each.
........
Model | Model ID | Role described by Google |
Gemini 4 Argon | gemini-4-argon | Most capable, complex reasoning and agentic UI workflows |
Gemini 3.8 Flash | gemini-3.8-flash | Recommended model for computer use |
Gemini 3.5 Flash-Lite | gemini-3.5-flash-lite | Low latency, cost-effective |
Gemini 3 Flash Preview | gemini-3-flash-preview | Preview model supporting computer use |
........
··········
HOW THE COMPUTER USE LOOP WORKS.
Computer Use in the Gemini API is not a hosted browser. The model never touches the screen itself; it proposes actions, and the developer's client carries them out. Google's documentation describes a four-step loop. The application first sends a request that includes the `computer_use` tool, the target environment, the user's instruction and a screenshot of the current state. The model replies with a function call, for example a click, accompanied by an `intent` field that explains what the action is meant to achieve, and it may attach a `safety_decision`. The client then parses the call, converts the coordinates to its own viewport and executes the action with an automation tool such as Playwright. Finally, it captures a new screenshot and returns it in a function result, and the loop repeats until the task is complete or is stopped.
Coordinates are handled on a normalized grid rather than in screen pixels. The model predicts positions on a 1000 by 1000 grid, with x and y expressed as integers from 0 to 999, and the client scales them to the real display. Developers therefore do not need to declare the screen resolution in the request. The official examples use a 1440 by 900 browser viewport, but the documentation does not present that size as a requirement.
In the GenerateContent API, the tool is declared as a `computer_use` entry in the `tools` list, and the `environment` field takes one of three values: `ENVIRONMENT_BROWSER`, `ENVIRONMENT_MOBILE` or `ENVIRONMENT_DESKTOP`. In the official Python examples the tool is built as `types.Tool(computer_use=types.ComputerUse(...))` with the environment passed as `types.Environment.ENVIRONMENT_BROWSER`, and the rest of the call is a standard `generate_content` request; Google's reference for this API requires version 2.7.0 or later of the Python SDK.
The Interactions API exposes the same capability through `client.interactions.create(...)`, with official examples in Python, JavaScript, Java and Go and a REST endpoint at `/v1beta/interactions`. The reference implementation in the documentation starts a Chromium browser through Playwright, creates an interaction with a prompt and a screenshot, runs the loop up to a turn limit and stops when the model returns text instead of further function calls.
··········
SUPPORTED ACTIONS IN BROWSER, DESKTOP AND MOBILE ENVIRONMENTS.
The set of predefined actions depends on the environment. Browser and desktop share the same vocabulary, which covers pointer actions, keyboard input, scrolling and navigation. The mobile environment, which Google describes as optimized for Android, replaces navigation and fine-grained mouse control with app-level actions such as opening an app or listing installed apps.
........
Environment | Predefined actions listed in the documentation |
Browser | click, double_click, triple_click, middle_click, right_click, mouse_down, mouse_up, move, type, drag_and_drop, wait, press_key, key_down, key_up, hotkey, take_screenshot, scroll, go_back, navigate, go_forward |
Desktop | Same action set as browser |
Mobile (Android-optimized) | open_app, click, list_apps, wait, go_back, type, drag_and_drop, long_press, press_key, take_screenshot |
........
Developers are not limited to that list. The `excluded_predefined_functions` option removes built-in actions, and custom functions can be registered alongside the tool. Google's documentation uses the example of a `yield_to_user` function that hands control back to a person, which is the natural building block for human-in-the-loop flows where the agent should stop and ask before continuing. Thinking levels can also be adjusted, and the documentation notes that lower levels generally strike a good balance for standard automation tasks, which is relevant for latency and cost in long loops.
··········
SAFETY DECISIONS, CONFIRMATIONS AND PROMPT INJECTION DETECTION.
The safety layer is the part of the feature that developers must actively implement. Each proposed action can carry a `safety_decision` that classifies it as allowed, as requiring confirmation (`require_confirmation`) or as blocked. When confirmation is required, the application is expected to prompt the user and, if the user agrees, to set `safety_acknowledgement` in the function result it sends back. Blocked actions should halt the loop or be handled explicitly. The documentation groups the policies behind these decisions into seven categories: financial transactions, sensitive data modification, communication tools, account creation, data modification, user consent management, and legal terms and agreements.
Developers can tune this behavior, but only partly. The `disabled_safety_policies` option overrides selected policies, and a system instruction can define custom safety boundaries. Google states that such overrides express a preference and that the model may still return `require_confirmation`, so an application that assumes the confirmation step will never appear is built incorrectly by design.
Prompt injection, the risk that a web page or app displays text crafted to hijack the agent, has its own control. The `enable_prompt_injection_detection` option checks screenshots for hidden adversarial instructions and blocks execution when it finds them. It is opt-in, with a default of `false`, and it is available for Gemini 3.5 Flash-Lite or later models. Beyond these switches, Google's best practices ask developers to keep a human in the loop for consequential steps, to run agents in a sandboxed virtual machine, container or restricted browser profile, to restrict navigation with blocklists or, more securely, allowlists, and to log prompts, screenshots, proposed actions, safety responses and executed actions for debugging and incident review. The documentation also acknowledges a more mundane limitation: unexpected pop-ups, notifications or layout changes can confuse the model.
··········
PRICING AND WHAT A COMPUTER USE SESSION COSTS.
Google's Gemini Developer API pricing page lists no dedicated price for Computer Use, so the cost of an agent session is the cost of the tokens the chosen model consumes, screenshots included. The page also shows scheduled increases for two of the four supported models: Gemini 4 Argon's standard prices double on December 1, 2026, and Gemini 3.8 Flash's double on January 1, 2027. Prices below are as listed on the official pricing page on October 30, 2026, in USD per 1M tokens on the paid tier.
........
Model | Input now | Output now | Cached input now | Scheduled change |
Gemini 4 Argon | $2.00 | $10.00 | $0.10 | $4.00 / $20.00 / $0.20 from Dec 1, 2026 |
Gemini 3.8 Flash | $0.75 | $3.75 | $0.075 | $1.50 / $7.50 / $0.15 from Jan 1, 2027 |
Gemini 3.5 Flash-Lite | $0.30 | $2.50 | $0.03 | None listed |
Gemini 3 Flash Preview | $0.50 | $3.00 | $0.05 | None listed |
........
To make the figures concrete, consider an illustrative browser task of 25 steps in which each request carries an average of 15,000 input tokens, covering the screenshot and accumulated context, and the model returns 400 output tokens per step including thinking. These are assumptions chosen for the example, not figures published by Google, and real token counts depend on screen content, history handling and thinking level. Under those assumptions a session consumes 375,000 input tokens and 10,000 output tokens. On Gemini 3.8 Flash at current prices that comes to about $0.28 for input plus about $0.04 for output, roughly $0.32 per session, or about $319 per 1,000 sessions; at the January 2027 rates the same workload costs roughly $0.64 per session. On Gemini 4 Argon it costs about $0.85 per session today and $1.70 after December 1. On Gemini 3.5 Flash-Lite it costs about $0.14 per session, or about $138 per 1,000 sessions.
The arithmetic shows why the choice of model matters more than the tool itself. Input dominates the bill, because every step resends visual state, so teams running high volumes of routine automation, such as regression testing of web forms, will feel the scheduled Flash and Argon increases directly and have an incentive to test whether Flash-Lite is accurate enough for their flows. Batch and Flex rates exist on the pricing page, but an interactive agent loop that waits for each response before acting is not a natural fit for batch processing.
··········
WHAT CHANGES FOR DEVELOPERS BUILDING AGENTS.
For developers already experimenting with the feature, the immediate change is status rather than syntax. The tool declaration, the action vocabulary and the safety mechanics described in the documentation are the same ones that teams have been testing; general availability signals that Google now supports them across both APIs for production use. Teams on the GenerateContent API should check that they run the required SDK version, and teams starting new agent projects can weigh the Interactions API, whose server-side state management simplifies long loops.
The second practical point is model selection. Gemini 3.8 Flash is Google's recommendation, Gemini 4 Argon is positioned for harder multi-step reasoning, and Gemini 3.5 Flash-Lite trades capability for latency and price. Because two of these models have announced price increases, projects that budget for 2027 should calculate costs at the scheduled rates rather than today's. The third point is responsibility: the client executes every action, so sandboxing, allowlists, confirmation prompts and logging remain the developer's job, and the documentation makes clear that skipping them is not a supported configuration.
The release also places Gemini more directly in competition with other providers that offer computer use through their APIs, including OpenAI's recent GPT-6.1 Terra release with computer use. Developers comparing Gemini options can also revisit the Gemini 4 Argon launch and its introductory API pricing and the recent change that turned on Gemini API request storage by default for new paid projects, which affects what data an agent loop leaves in Google's logs unless storage is disabled.
··········
TECHNICAL SYNTHESIS: WHAT IS ESTABLISHED AND WHAT REMAINS OPEN.
The established facts are clear. Google's official Gemini API release notes record Computer Use as generally available on October 30, 2026, for both the Interactions and GenerateContent APIs. The documentation lists four supported models, three environments, a defined action vocabulary per environment, normalized 0 to 999 coordinates, a safety-decision mechanism with seven policy categories, and opt-in prompt injection detection for Gemini 3.5 Flash-Lite and later. No separate Computer Use fee appears on the pricing page, so costs follow each model's token prices, two of which are scheduled to double.
Several points remain open. The documentation still describes Computer Use as a preview capability in its warning text, which leaves the precise meaning of general availability, in terms of service commitments, undocumented on the feature page itself. Google has not published, in the material reviewed for this article, new benchmark figures tied to the general availability release, nor official per-screenshot token counts that would let developers predict session costs without measuring them. Developers should treat the release as a stable API surface for building supervised agents, and measure accuracy and token consumption on their own interfaces before committing workloads that act on real accounts or data.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
