Gemini 3.5 Flash Computer Use API Is Now a Built-in Tool: The Routing Decision That Changes Your Agentic Stack

Gemini 3.5 Flash now ships computer use as a built-in tool alongside Search and Maps grounding — no separate model required. That consolidation changes how operators route browser and desktop automation workloads.

Published via Google DeepMind Blog

Archive item produced with AI assistance from the cited source and published without individual review. Editor of record: Joe Werner.

Editorial illustration of a Gemini Flash routing diagram with computer-use tool highlighted alongside search and maps grounding, muted professional palette

Google DeepMind has shipped computer use as a native built-in tool in Gemini 3.5 Flash — the same model already handling function calling, Search grounding, and Maps integration. That is not an incremental feature update. It collapses a two-model routing decision into a single endpoint, and it changes what "agentic browser automation" costs operators at inference time.

If your team routes computer use tasks to a separate standalone model, this changes the architecture decision.

What happened

Previously, Gemini computer use required routing to a dedicated standalone model (gemini-2.5-computer-use). The new release integrates computer use directly into gemini-3.5-flash as a built-in tool, alongside existing native tools like Search and Maps grounding.

The practical change:

  • One endpoint, multiple tool modes. Developers call the Gemini API with the computer use tool enabled on the same Flash model they already use for text, function calling, and grounding. No separate model specifier.
  • Enterprise safeguard system. Two optional safety layers are now available: explicit user confirmation gates for sensitive or irreversible actions, and automatic task-halting when an indirect prompt injection is detected.
  • Availability. Live on both the Gemini API (ai.google.dev) and Gemini Enterprise Agent Platform (console.cloud.google.com/agent-platform).

Why it matters for AI engineering teams

The shift from standalone model to built-in tool has three concrete operator consequences.

1. Routing simplification. Any team that previously had a conditional routing path — "if computer use task → route to gemini-2.5-computer-use, else route to gemini-3.5-flash" — can now collapse that branch. The Flash model handles both workloads. Fallback logic, rate-limit tracking, and billing reconciliation shrink from two model identifiers to one.

2. Token cost baseline changes. The standalone computer use model carried its own pricing tier. Computer use as a built-in Flash tool falls under Flash pricing. Operators need to recheck cost-per-task projections for browser and desktop automation workloads — in most cases, Flash pricing should be lower or comparable, but the token consumption profile for computer use tasks differs from standard text generation.

3. Safety architecture is now a gate configuration, not a deployment choice. The two enterprise safeguard options (confirmation gates, injection detection) are configured per-call, not at the deployment level. Operators who previously isolated computer use to a separate model as a security boundary now need to implement equivalent controls via these per-call flags. "Defense-in-depth" — sandboxing, human-in-the-loop, strict access controls — is still recommended by Google alongside the built-in safeguards.

The router/operator angle

For teams building multi-step agentic pipelines, the most important routing implication is prompt injection governance. Computer use agents operate in live browser and desktop environments where they can encounter adversarially crafted content — pages designed to hijack the agent's action sequence.

The new safeguard system gives operators two levers:

  • Confirmation gates — require explicit human approval before sensitive or irreversible actions. Use this for production pipelines that touch user accounts, file systems, or external APIs.
  • Injection detection with auto-halt — the model halts the task rather than continuing after detecting a suspected injection. This is opt-in, not default.

Neither replaces sandboxing. The guidance from Google is explicit: combine these features with secure browser sandboxing, human-in-the-loop verification, and restricted access controls. For AI gateways routing computer use traffic, this means the routing policy needs to include which environment the tool is running in — a sandboxed test environment can have looser gates than a production agent touching customer data.

What to watch if you route Gemini traffic:

  • Identify whether any current routes target gemini-2.5-computer-use or a computer-use-specific endpoint. These can now be consolidated to gemini-3.5-flash with the tool flag enabled.
  • Audit cost-per-task projections if you're tracking model-level spend separately for computer use vs. text workloads.
  • Review the safeguard configuration in your agent wrapper — the confirmation gate and injection detection need to be explicitly enabled; they are not on by default.
  • Check the Gemini API computer use docs for the tool invocation syntax and safety best practices reference.

What TheRouter users should watch or try

If you route Gemini traffic through TheRouter, the relevant change is on your model selection configuration. If you had a separate routing rule for computer use workloads pointing to the standalone computer use model, that rule can now be simplified — point those workloads to gemini-3.5-flash with the computer use tool enabled.

Watch the /models/ catalog for updated Gemini 3.5 Flash endpoint details. The safety gate configuration is handled at the request level in your agent code, not in the routing layer — but the routing layer determines which account and rate-limit bucket that traffic hits.

Help & contact