Computer Use APIs Compared: Gemini GA vs Claude vs OpenAI Agents API

Three vendors now sell a way for a model to click around a screen, and they disagree on the one question that matters for safety: who runs the browser. For Claude and Gemini, you do. For OpenAI, you can, or OpenAI's hosted browser does, and then the approval model changes. This post compares the three on where the environment runs, how approvals work and what to lock down, using vendor pages I read on 30 October 2026.

I ran none of this. No API keys were available, so there are no latency, cost or success-rate numbers here, and I'm not repeating vendor benchmark claims. If you only want Claude's side in depth, start with the Claude computer use API guide; for tooling beyond these three, see AI browser agents compared.

What shipped, with dates?

• Gemini: the changelog entry for 30 October 2026 says "Released the Computer Use tool to general availability (GA) across the Interactions and GenerateContent APIs."
• OpenAI: the changelog says "Added computer use to the Agents API" on 29 September, with agents working in an OpenAI-hosted browser. The Agents API itself went to public beta on 10 September.
• Claude: per the release notes, computer_toolset_20260801 left beta on 19 August 2026 (no beta header, batch actions, zoom on by default). On 7 October the Python and TypeScript SDKs added beta classes for the browser and computer use tools, so the SDK runs the tool loop, your URL and file policies and your approval callback.

A correction to what you may read elsewhere: the Claude toolset is not an October launch. October 7 was the SDK helpers.

Where does the browser actually run?

Two practical notes. Claude's tools are not available in Claude Managed Agents at the moment per both docs pages, so the "managed" route does not exist there. And the Gemini docs recommend gemini-3.8-flash for computer use on the page I read, while gemini-4-argon is also listed.

How does each one handle approvals?

This is where they differ most.

Gemini attaches a safety_decision to an action: allowed, require_confirmation or blocked. On require_confirmation you ask the user, then set safety_acknowledgement in the function_result. Policy categories include financial transactions, sensitive data modification, communication tools, account creation and legal terms. You can override some with disabled_safety_policies, but the page says your app "should always implement safety decision handling regardless of configured overrides".

Claude has no built-in permission system. The computer use page says approval is your job and tells you to check consequential actions "before each block in a batch runs", because a batch can finish a multistep action in one turn. The browser docs say the API doesn't filter URLs, so your navigate handler must refuse schemes other than http or https, using a URL parser rather than a string prefix, and enforce a domain allowlist at the network layer, re-checked after redirects.

OpenAI splits it two ways. In the Responses API, pending safety checks stop the sample until you add an approval callback. In the Agents API hosted browser, the user must approve each new website origin, "including public websites", and enabling network access does not approve them. Sign-in requests come through as browser_authentication (email, password and verification codes; passkeys and QR sign-in aren't supported), and only the main agent can ask. The same page then says the important part: origin approval does not enforce confirmation before individual actions like purchases. To guarantee confirmation, "restrict the browser to resources that can't perform those actions, or use a browser runtime you control".

A decision rule: if a wrong click can spend money or send messages, run the environment yourself (any of the three) and put the approval check in your executor. Use OpenAI's hosted browser for read-mostly tasks, where an origin allowlist is enough.

What does each vendor say about prompt injection?

None says it's solved.

• Claude: the model "follows commands found in content even when they conflict with your instructions". Anthropic runs classifiers on tool outputs such as screenshots to steer the model into verifying instructions with the user, but the page says your precautions "remain important even with these classifiers in place".
• Gemini: detection is opt-in, available for gemini-3.5-flash-lite or later, and blocks execution when it finds hidden adversarial instructions in a screenshot. The page also warns computer use "may contain errors and security vulnerabilities" and advises against critical decisions and sensitive data.
• OpenAI: "Treat screen content as untrusted", and text in a page or tool result "cannot grant permission or override the user's instructions".

For the underlying risk, read prompt injection in tool-using agents and AI coding agent safety and sandboxes.

What should every setup have, whichever vendor?

This is a checklist, assembled from the three vendor pages; no single page lists all of it.

1. A dedicated VM or container with minimal privileges and a fresh browser profile with no saved credentials.
2. A domain allowlist enforced at the network layer, not only in the prompt.
3. A scheme check (http and https only) on every navigation.
4. A code-level approval step before purchases, messages, account changes and accepting terms. Check each action in a batch, not each turn.
5. Step, time and cost limits (OpenAI's guide suggests bounding runs this way). Screenshots add up: Claude's page puts each at roughly 1,000 to 1,800 input tokens.
6. Logs of every action and screenshot. Gemini's page recommends detailed logging.
7. A human-visible record of what the agent did, and user consent before you turn it on. Claude's docs ask you to inform end users of the risks first.

An unrun sketch of check 4, vendor-neutral, that you'd call from whichever executor you write:

HIGH_RISK = {"purchase", "send_message", "change_account", "accept_terms"}

def allowed(action_kind: str, approved_by_human: bool) -> bool:
    """Return False so the executor skips the action and reports why."""
    if action_kind in HIGH_RISK and not approved_by_human:
        return False
    return True

The hard part isn't this function. It's classifying an action as high-risk before it runs, which the model's own labels can't be trusted to do. Classify by the target (domain, form, button text) in your code.

How do I choose?

Compare on your own task before committing. I'd write five or ten real tasks, run them on each vendor with the same sandbox and log success, steps and cost. Treat any vendor chart as a starting hypothesis. For the Agents API side, see Agents API vs Agents SDK.

What I could not verify

• Pricing for computer use on any vendor. The pages I read did not state it, apart from Claude's screenshot token estimate. Check each pricing page.
• Gemini's GenerateContent request shape for computer use; the docs example I read uses the Interactions API.
• OpenAI's Agents API computer use release stage. The page uses the OpenAI-Beta: agents=v1 header but doesn't label it.
• The tail of the Claude computer use, browser use and OpenAI Agents API computer use pages (roughly the last 10 to 25 percent of each), which the fetch tool cut off. Something there may qualify the points above.
• Success rates, speed, and any "which is best" claim. I have none.