THE SHORT ANSWER
● Testing what you just built — Cursor - iOS Simulator is the headline example
● Automating arbitrary desktop work — Claude - computer use on Windows since 3 April 2026
● Published desktop benchmark — Claude - OSWorld 2.1 at 81.8% for Opus 5.5, 80.1% Sonnet 5.5, 72.4% Haiku 5.5
● Both — Cost money in screenshots. Driving a GUI means image tokens
Cursor announced Computer Use on 23 October: its coding agents can now operate desktop applications directly, with the iOS Simulator as the example given. Anthropic has shipped computer use for considerably longer, adding it on Windows on 3 April 2026 and extending beta SDK support for computer use and browser use alongside Haiku 5.5 on 7 October.
Side by side
| Cursor Computer Use | Claude computer use |
|---|
| Announced | 23 October 2026 | Windows support 3 April 2026 |
| Primary purpose | Verify code the agent wrote | General desktop automation |
| Headline target | iOS Simulator and desktop apps | Any application on the desktop |
| Sits inside | A coding workflow | The model, via API and SDK |
| Published benchmark | None yet | OSWorld 2.1: 81.8% Opus 5.5 |
| Who it is for | Developers shipping an app | Anyone automating a desktop task |
What Cursor's version changes
Until now a coding agent's feedback was textual: compiler output, test results, logs. All of it answers "did this build" rather than "does this work". Driving a running application covers the failure class that compiles cleanly and behaves wrongly, which in mobile development is most of the interesting ones. For iOS specifically, where the simulator is the normal test surface, it removes the step that previously required a human to look at a screen.
That is a narrow capability aimed precisely. It is not trying to automate your desktop; it is trying to let an agent check its own work before handing it back.
What Anthropic's version is for
Anthropic publishes OSWorld 2.1 numbers, which is the relevant signal: 81.8% for Opus 5.5, 80.1% for Sonnet 5.5, 72.4% for Haiku 5.5 - against 15.7% for Haiku 4.5, which is the generational jump that made this usable at the cheap end. Those are general desktop tasks, not coding verification. The use case is a workflow that crosses applications and has no API.
Haiku 5.5 at $0.10 input per million with computer use in beta is the combination to watch, because screenshot-heavy automation is exactly the workload where per-token price decides whether a thing is viable.
The cost both of them share
Driving a graphical interface means screenshots, and screenshots are image tokens. A ten-step interaction is ten images plus reasoning over each. Neither vendor has published a per-task cost for GUI work, and the Shandong harness study published the same week is a useful warning here: on coding agents, scaffolding choices moved cost by up to 3x with no consistent accuracy gain. Screenshot loops are scaffolding with a camera attached.
Measure it on your own task before building a workflow that depends on it. Count steps and screenshots, not features.