Most apps have no API. Most have no MCP server either.
Your agent can still use them. computer-cli, the computer-use tool your agent calls, drives the screen and keyboard like a person would.
We ran it on 20 hard OSWorld tasks, three times each, against Cua's MCP server. Same model, same tasks.
computer-cli passed 88%, Cua 84%. Two passes in 58 runs is within chance, so call it a tie.
The savings are the real story: 16% lower cost, 26% fewer input tokens, 20% fewer model calls.
On these tasks, a $10M bill would have come to $8.4M.
Across the benchmark, that's 10.4 million tokens your agent didn't have to read.
What OSWorld measures
OSWorld is the benchmark most computer-use agents get measured on.
Each task boots a real Ubuntu machine with real apps: LibreOffice, Thunderbird, GIMP, Chrome, VS Code. The agent gets an instruction, like "create a pivot table in a new sheet that counts each invoice number." When it stops, a script checks the files and settings it left behind.
No partial credit.
We drew 20 tasks from the hardest domains: multi-app workflows, LibreOffice Calc, Writer and Impress, and Thunderbird. Claude Sonnet 5.5 did the work in Claude Code both times. The only thing we changed was the computer-use tool it could call: computer mcp from computer-cli 0.1.12, or Cua's cua mcp.
Task by task
computer-cli used fewer model calls on 15 of the 20 tasks.
The gap is widest on the long multi-app tasks. Setting an emailed document's image as the wallpaper took 23 calls with computer-cli and 42 with Cua. Brightening a slide's image and saving it took 13 against 22.
Where the tokens go
A computer-use agent pays for every screenshot it looks at. Then it keeps paying, because each image stays in the context the model rereads on every later call.
So fewer calls and fewer images compound. Four things in how computer-cli's MCP server works are the likely reasons. We didn't run an ablation, so we can't tell you how much each one is worth.
- One call acts and looks. Every action returns the screen after it (since 0.1.6), once the screen has stopped changing (since 0.1.10). The agent never spends a call just to check that a click landed.
- Several actions, one image. When the agent sends a burst of actions, all but the last skip the screenshot with
screenshot: false(0.1.11). Five steps cost one image, not five. - A whole row in one go.
type-texttypes\tas Tab and\nas Enter (0.1.11). A spreadsheet row or a form fills in one call. Before that, those keys went out as codes the machine ignored, and the agent retyped cell by cell. - Click where you look. Screenshots come back 1280 pixels wide. The agent clicks in those pixels and the server maps them to the real 1920×1080 screen (0.1.11). No math for the model to get wrong.
0.1.12, the version we tested, only made screenshots faster to capture. That changes time, not tokens.
Here's one Calc task (sum two columns into a new sheet), on our first cut and on the released build. Both passed.
How we kept it honest
If you pick tasks after you see where you win, you're fooling yourself. So we wrote the rule down before any agent ran. Times are UTC, October 20, 2026.
- 09:46. The rule is written: the pool (OSWorld-Verified
test_allat commitb138d34, the six domains), the exclusions, seed20261020, the draw, the tools, three trials, and scoring by OSWorld's own checker. - 09:47 to 09:54. A run with no agent walks the seeded order and keeps the first 20 tasks that set up and score cleanly. All 20 did (walk.txt).
- 09:54. The task list is frozen. Its SHA-256 is
d1520f7f777797bfae64f0d5c47aea2baac996c2ba63f526847532c562894c5a. - 09:55. The first agent run starts. 120 runs follow, each on a fresh machine.
We left out the 39 tasks in OSWorld's test_small split, because we used them while building 0.1.11 and 0.1.12. We also left out Google Drive, infeasible and container-degraded tasks.
One environment fix applied to both tools: Chrome and VS Code can't start in Cua's stock OSWorld container under Docker's default security profile, so both started with --no-sandbox (Dockerfile.txt).
Every run is in results.txt, with its metrics in runs.csv. python3 score.py runs.csv reproduces score.txt from those files alone (score.py). DEVIATIONS.txt lists what didn't go to plan: a first launch that failed before any agent started, two debug runs we excluded, and how we scored runs that hit the turn cap. README.txt explains every file.
Where Cua does better
Speed. On the scored runs it's a tie: 52.8 seconds per run for us, 51.5 for Cua. Count the four runs that hit the turn cap and we're 14% slower, 62.0 seconds against 54.2. Our two capped runs took 329 and 330 seconds; Cua's took 139 and 130.
Our time per action includes waiting for the screen to settle and capturing it over VNC. Cua's tool calls returned faster in our runs. 0.1.12 halved our capture time; the settle wait is next.
Cua also needed far fewer calls on three tasks. Converting a Word reference list to LaTeX took it 20 calls to our 37 (neither passed). An academic homepage took 22 to our 39. Transposing a table took 7 to our 12.
And on setting up a GitHub project's Python environment, Cua passed once. We never did.
Try it
npm i -g @phnx-labs/computer-cli
# any VNC machine, as an MCP server for Claude Code
claude mcp add computer -- computer mcp --host vnc://localhost:5901
The same tool drives Mac apps through Accessibility and Windows apps over SSH. It's the computer your agent uses on Rush when a job needs one: a real machine in its own sandbox, and the result back with the trajectory behind it.
