Claude Computer Use (post-Vercept) vs Codex Background CU vs Operator vs Gemini: Four Bets on Letting AI Drive the Mouse

Claude posts 72.5% on OSWorld and three frontier labs immediately raise the stakes — the question is no longer can a model drive a computer, it is where the computer lives. Anthropic bets on your sandbox, OpenAI bets on a hardened cloud Chromium, Google bets on the browser tab. As of late June 2026, those three bets do not converge — and architecture, not benchmark score, decides which one fits your job.

At a glance

Four shipping computer-use offerings, three architecturally opposite bets about where the mouse should run. The table sets the basics; the chart and heatmap below it show where each one actually leads.

Vendor	Approach	Deployment	OSWorld %
Claude Computer Use (post-Vercept)	Screenshot + mouse/keyboard tool over any OS	Your VM, container, or remote desktop	72.5%
OpenAI Codex Background CU + Operator	Cloud Chromium in a managed sandbox	OpenAI infra; you stream the screen back	38% (Operator, OSWorld)
Gemini Computer Use	Browser-tab agent in Workspace + Chrome	Google infra, tied to a signed-in session	32%
browser-use (OSS baseline)	Open-source Playwright loop over any model	Your infra; BYO model	26%

Snapshot as of late June 2026; benchmark figures change weekly and the leaderboard is contested.

OSWorld is the apples-to-apples benchmark — Claude's 34.5-point lead over the runner-up is wider than the spread across the other three entrants combined.

Where each entry leans hardest. Claude is the only full-desktop bet; OpenAI dominates the safety-model column because containment is its product; browser-use is the only weights-available row.

Claude Computer Use

Claude reads the screen and emits mouse/keyboard tool calls into a host you operate — VM, container, remote desktop, or bare-metal Linux.

Post-Vercept architecture

The Claude computer_use tool is deliberately small. The model receives a screenshot, decides on the next action, and emits one of a handful of primitives: screenshot, mouse_move, left_click, type, key, scroll. That tiny interface is the whole abstraction — it carries no opinion about what is on the other side. Anthropic ships reference harnesses for an Ubuntu container, a Wayland desktop, and a remote VNC target, but the protocol is the same in each case. This is the agent loop reduced to its photo-and-fingers minimum: perceive a pixel buffer, decide an input event, act, observe the next frame. Nothing about it assumes a browser, a DOM, or even a particular OS — if you can take a screenshot of it and inject events into it, Claude can drive it.

The Vercept integration is what turned that minimal tool into something that wins OSWorld. Vercept built a perception stack that handles sub-pixel widget targeting, multi-monitor coordinates, font-rendering drift between platforms, and the long tail of UI affordances that confuse pure VLMs (right-click menus, native file pickers, tooltips that occlude buttons). Anthropic absorbed it and bound the result directly into the model's vision pathway. The public API surface barely changed; the success rate on real desktop tasks roughly doubled.

Why "your sandbox" wins

Because the runtime is yours, the reach is whatever your runtime can touch. That means desktop apps with no web equivalent — Photoshop, Final Cut, Logic, a legacy ERP client that never got a SaaS port. It means a terminal, with real shell access and real filesystem mutation. It means installed credentials: a kubeconfig, a logged-in SSH agent, a 1Password CLI, a database client pointed at staging. Browser-only agents fight every one of those moments by routing through a hosted Chromium that does not own the file system; Claude does not, because the file system was never abstracted away. The same property that makes Claude the hardest of the four to deploy safely (you have to build the sandbox) is the property that makes it the only one that can do work outside a tab.

The acquisition context

Anthropic announced the Vercept acquisition in early June 2026 alongside an update to the Claude 4 family's computer-use capability. The public computer_use tool signature did not break; what changed is the perception quality behind it. There is no separate "Vercept SDK" to install — the integration shipped as a model capability, not a new product surface. Practically: anyone who already had a working Claude Computer Use harness saw their pass rate jump after the model update without changing a line of harness code. That is the whole shape of the bet — keep the tool surface flat and uninteresting, put all the engineering inside the model that drives it.

OpenAI Codex Background CU + Operator

OpenAI runs the browser. You watch it, approve credential moments, and read the audit trail; you never own the process.

Cloud-VM Chromium architecture

OpenAI's bet is the inverse of Anthropic's: the computer should never touch yours. Operator and Codex Background CU both run inside an OpenAI-operated Linux VM with a hardened Chromium and nothing else of consequence. The agent acts via DOM events as much as via raw screenshots, observes through a video pane that streams back to the user, and writes a full action log the user can scroll. Containment is not a feature bolted on top — it is the architecture. The model cannot escape the VM because the VM is the entire reachable world.

Codex Background CU (shipped April 16, 2026)

Codex Background CU extended that runtime into asynchronous, long-running computer-use tasks scoped to development work. "Background" is load-bearing: the agent runs without an attached human watching the stream, pauses on credential prompts (which surface as approval requests in the Codex UI), and resumes when approved. The integration with Codex itself is what makes the architecture pay off — the same VM that drives the browser also has a checked-out repo, a working terminal, and the Codex code-edit tool, so a "go file the bug, reproduce it in the dashboard, then write the fix" task does not have to leave the sandbox. The constraint is the same one Operator wears: you get reach within the VM, not on your machine.

Operator's 87% travel-booking number — what that actually measures

Operator's public marquee number is 87% on a travel-booking eval — and that figure is precisely as load-bearing as it sounds, no more. The eval is a curated set of end-to-end booking flows on a handful of major sites with stable, well-rehearsed DOM structures. It is not OSWorld; it is not a measure of general desktop competence. Inside that narrow target, Operator is genuinely strong — the cloud Chromium plus a fine-tuned model for web flows is the right architecture for predictable, repeated forms. Outside it — on a site Operator has not seen, on a desktop app, on a terminal — the same architecture is the wrong one. Read the number for what it is: a domain-specific high-water mark, not a generalization to the OSWorld floor.

ChatGPT Agent integration in early 2026

In early 2026 OpenAI folded the Operator runtime into ChatGPT itself under the "Agent" surface, so consumer users invoke computer use from the same conversation thread they use for everything else. The architecture did not change — it is still a cloud VM, still Chromium, still streamed back through a pane — but the distribution did. The practical consequence is that the "consumer assistant that can also book your flight" path now goes through OpenAI's sandbox by default, and any enterprise pattern that wants the same shape inherits the same containment story whether they want it or not.

Gemini Computer Use

Where it wins

Gemini's bet is the narrowest of the three and the most coherent for what it targets: a browser-tab agent, tuned for low latency, with first-class access to a signed-in Google Workspace session. Gmail, Calendar, Docs, Sheets, Drive — the agent moves around inside an already-authenticated context the user expects it to know. The same property is true for any web app where the user is signed in via Google SSO. Gemini's latency on these flows is markedly lower than Operator's, partly because the action surface is smaller (browser tab, not VM) and partly because Google has spent two years tuning Chrome to be fast under instrumentation. For "summarize my inbox and reply to the three urgent ones," this is the right shape.

Where it doesn't

Off the page, Gemini does not exist. There is no desktop reach, no terminal, no filesystem, no native app drive. The architecture is a deliberate choice — the browser tab is the entire universe — and the cost of that choice is everything the other two architectures can do that Gemini cannot. On OSWorld, that constraint shows up as a score in the low thirties, not because the model is weak but because most OSWorld tasks happen outside a single browser tab. If your workload is browser-only and Workspace-shaped, Gemini is the best price-per-task option on this list. If it is not, the architecture excludes you on the first try.

Cross-cutting comparison

Surface

This is the axis where the three vendors are most violently apart. Claude treats the surface as "whatever can take a screenshot and accept input events" — full desktop, terminal, filesystem, multiple monitors, native apps, the lot. OpenAI narrows it to "a Chromium instance we operate," which is wider than a single tab (multiple tabs, downloads into a sandboxed FS, a terminal in the Codex variant) but stops at the VM boundary. Gemini narrows it further to "the current browser tab in a signed-in Workspace session." Three concentric circles — and the choice of which circle to commit to forces every other architectural decision downstream.

Deployment

Deployment shape mirrors the surface choice exactly: Claude runs on whatever you provision (your VM, your container, your Mac, your remote VDI), OpenAI runs on OpenAI infrastructure with a streamed pane back to you, Gemini runs on Google infrastructure inside a signed-in browser context. The operational consequence is who carries which risk. With Claude you carry sandbox construction, OS hardening, and credential hygiene yourself; the upside is that nothing about your work has to leave your boundary. With OpenAI and Gemini you outsource the sandbox entirely; the cost is that the data the agent sees passes through the vendor's runtime, which moves the compliance conversation from "did we build the sandbox correctly" to "can we accept this vendor's data path."

Safety model

The three labs answer "what stops the agent from doing damage" with three different primitives. OpenAI answers with containment: the agent literally cannot reach anything outside the VM, and credential moments surface as explicit human-in-the-loop approvals in the streaming UI. Gemini answers with scope: the browser tab is the boundary, the signed-in session is the trust unit, and Google's existing account safety machinery (re-auth on sensitive flows, anomaly detection) carries the load. Claude answers with delegation: the safety model is whatever sandbox you built, which can be stronger than either of the other two (kernel-level capability constraints, ephemeral VMs, no persistent credentials) or much weaker (running the agent on your laptop with your logged-in sessions, no isolation) — the responsibility is unambiguously yours. Pick the one whose default failure mode matches what you can actually operate.

Latency

Gemini is the fastest of the three on the workloads it targets, because the action surface is small and Google has tuned the round-trip for browser-tab interactions. OpenAI is the middle of the pack: the VM round-trip adds tens to low-hundreds of milliseconds per action, and the model itself is doing more reasoning per step on the harder Operator and Codex flows. Claude is the slowest per action — screenshots are heavier than DOM events, and the model deliberately re-perceives the screen between most steps to handle the desktop-wide reach — but it is also the only one of the three that can complete classes of tasks the other two cannot start. The right axis for comparison is not "latency per action" alone; it is "wall-clock time to complete the actual job," and on multi-app desktop workflows Claude's per-action overhead is dwarfed by the fact that it does not have to fall out of the sandbox and back into a human handoff.

When to pick which

Use case	Pick Claude if…	Pick OpenAI if…	Pick Gemini if…
Browser-only web task	You want the highest absolute success rate and are willing to run the browser yourself in a container.	You want the vendor to run a hardened Chromium and stream it back, with credential approvals in the UI.	The site is inside a Workspace-signed-in context and latency per action matters more than absolute generality.
Desktop app automation	The work is in Photoshop, Logic, a native ERP client, or anything else without a web equivalent — this is the only architecture that reaches it.	Not a fit — Operator and Codex CU stop at the Chromium boundary.	Not a fit — Gemini does not exist outside the browser tab.
Terminal-driven dev work	You want one agent that drives the browser, the shell, and the editor in the same session against your real repo.	Codex Background CU's VM ships with a terminal and a checked-out repo — fits if you can accept that the repo lives in the OpenAI sandbox.	Not a fit — no terminal surface.
Regulated enterprise (audit, credential containment)	You can build (and prove) an ephemeral, kernel-isolated sandbox per session and keep all credentials inside your boundary.	You accept the OpenAI cloud VM as the containment boundary and rely on its audit log and human-in-the-loop credential approvals.	Your compliance regime already accepts Google Workspace as the trust unit and you only need browser-tab reach.
Consumer assistant	The user is a power user who wants the assistant to touch real apps on their actual machine.	The user lives in ChatGPT already and the "Agent" surface inside that conversation is the natural entry point.	The user lives in Gmail, Calendar, and Docs and wants the assistant to act inside that signed-in context.

FAQ

Can I run Claude Computer Use on Windows?

Yes, but the supported path is an isolated Windows VM (Hyper-V, Parallels, or a cloud Windows desktop) rather than your daily-driver host. Anthropic's reference harnesses target Linux containers first, but the computer_use tool itself is OS-agnostic — anything that can take a screenshot and inject mouse and keyboard events qualifies. The reason to keep it in a VM is the same reason as on Linux: the sandbox is your responsibility, and running the agent against your real desktop puts your real credentials in scope.

How safe is OpenAI's cloud VM with my credentials?

Safer than running an agent against your local machine, by construction — the agent cannot reach anything outside the VM, and credential moments (logins, payment confirmations, sensitive form fields) interrupt the run and surface as explicit approvals in the streaming UI. The trade is that the credentials you do hand over (a session cookie, a saved password, a 2FA code) live in OpenAI's runtime for the duration of the task. That is acceptable for most consumer flows and for many enterprise flows behind appropriate data-processing agreements; it is not acceptable for credentials you have committed never to expose to a third-party VM, in which case Claude's "your sandbox" model is the architectural fit.

What does OSWorld actually measure?

OSWorld is a benchmark of real desktop tasks on a real Ubuntu environment — file management, multi-app workflows, terminal commands, browser flows, office documents — scored by whether the agent reaches the correct end state, not by trajectory similarity. It is intentionally hard for browser-only agents because most of its tasks span more than one app. A 72.5% score means the agent completes roughly three out of every four tasks end-to-end; the human baseline on the same set is in the low nineties. The "floor not milestone" framing in this post means: a year ago the leading score was in the teens; now 72.5% is what the next entrant has to beat to be taken seriously.

Is Vercept's technology in the public Claude API?

Yes — the integration shipped as a model capability, not a separate SDK. The public computer_use tool signature is unchanged, but the perception quality behind it (widget targeting, multi-monitor handling, font-rendering robustness) improved as a result of the acquisition. There is no "enable Vercept mode" flag; if you are calling the current Claude computer-use endpoint, you are using it.

Which one wins for booking travel?

Operator wins inside its lane — its 87% number is on a curated travel-booking eval against well-known sites, and the cloud-Chromium architecture is the right shape for predictable, repeated form flows. Outside that lane, on travel sites Operator was not tuned for or for itineraries that require touching a desktop calendar app, the comparison reopens. Gemini is competitive when the booking lives inside a Google-signed-in context. Claude wins when the task crosses out of the browser entirely — for example, exporting the confirmation PDF, attaching it to a Keynote deck, and emailing it from a native client.

What about open-source options (browser-use, CogAgent)?

browser-use is the most-cited OSS baseline — a Playwright loop over any model, scoring around 26% on OSWorld with a strong general-purpose model behind it. CogAgent and the broader VLM-driven OSS lineage (UI-TARS, ShowUI, OS-Atlas) sit in a similar range. The reason to use them is not benchmark parity with Claude — none of them is close — but architectural control: open weights, your inference path, no third-party runtime. For research, for environments where the closed-source vendors are not available, or for products that need to ship the model into the user's own infrastructure, the OSS baseline is the only viable option and the gap to the frontier is closing faster than the closed leaderboard suggests.