What does it cost to give an AI one more try at using a computer?

Oct 9, 2026 · Technical · Part 1 of 2

Training an AI to write text mostly means pushing numbers through graphics cards. Training an AI to use a computer is stranger. The model needs a computer to practice on. It opens Chrome. Clicks something. Types into a field. Gets a popup it didn't expect. Fails. The computer gets wiped back to how it started. It tries again.

Now do that hundreds of thousands of times.

I'm building Drums, which is about making those attempts cheaper, so I wanted to understand exactly what one attempt costs before I claimed anything. I read four papers: the original OSWorld paper that defined how these practice computers are built [1], OSWorld-Human, which timed where every second goes [2], OSWorld-Science, which ran 1,500 attempts on real scientific software and priced them [3], and CUA-Sandbox, which asks whether each attempt really needs its own computer [4]. This post covers the first three. The second post covers the fourth.

No jargon without a definition, I promise. Here's what we're going to find out.

First, what is an "attempt"?

The research word is rollout. A rollout is one complete try at one task: the computer is put into a known starting state, the model is given an instruction like "update my bookkeeping sheet with these receipts", the model takes a series of steps, and at the end a script checks whether the job got done. That check produces a score, usually 0 or 1, which is the only thing the training process actually learns from.

The OSWorld paper is where this got standardized for desktop computers, so it's the best place to see what a rollout is made of [1]. OSWorld is a set of 369 tasks on an Ubuntu desktop with real apps: Chrome, LibreOffice, GIMP, VLC, Thunderbird, VS Code, a terminal. Every task comes with two things: a recipe for setting up the starting state, and a script that inspects the final state to decide whether the task succeeded. Nine graduate students spent about 1,800 hours building those recipes and scripts. That's a lot of effort for 369 tasks, and it tells you something: the hard part of building a training environment isn't the computer, it's deciding what "done" means.

Notice the shape. A rollout begins before the model does anything (boot, restore, set up) and ends after the model is done (tidy, grade, wipe). The model only lives in the middle. Everything around the middle is infrastructure, and infrastructure is what you pay for N times when you run N rollouts.

How the practice computer is built

OSWorld runs each task inside a virtual machine, or VM: a complete pretend computer, with its own operating system, running as a program on a real one. The paper gives two reasons [1]. A VM is a safe box, so if the agent runs rm -rf on the wrong folder, it only destroys the pretend computer. And a VM can be snapshotted: you can freeze its entire state, disk and memory and all, and later jump straight back to that frozen moment. Snapshots are how "wipe and try again" works without reinstalling anything.

Inside the VM lives a small server. The host sends it an action as a line of Python using the pyautogui library, something like pyautogui.click(300, 540), and the server runs it. The screen is fixed at 1920 × 1080 because that was the most common real-world resolution when the paper was written, and the model's clicks are expressed in those pixels [1].

How the starting state is restored

This part is more interesting than it sounds. You might expect each of the 369 tasks to have its own snapshot: freeze the computer with the right spreadsheet open, and restore that. OSWorld deliberately doesn't do this. The paper explains that a full snapshot stores a lot of hardware state the task doesn't care about, so one per task would cost gigabytes each [1]. Instead, setup is three stages:

File this away, because it's the first clue to the question that drives the second post. OSWorld's authors already noticed that 369 tasks don't need 369 computers' worth of saved state. They need one computer plus 369 small differences. Most of the computer is identical across tasks, and across rollouts of the same task it's identical by definition.

Where the time goes inside the loop

So a rollout is some overhead, then a loop, then some overhead. How long is the loop, and what's it spending its time on? The OSWorld-Human paper from UC San Diego is the first careful answer [2]. They took two of the best open-source agents at the time, Agent S2 and GTA1, ran them on 39 OSWorld tasks, and timed every single piece: taking the screenshot, calling the model to plan, calling a second model to find the exact pixel, performing the click, calling the model again to reflect on what happened.

The headline finding is blunt. Changing two paragraphs to double spacing in a document took the agent 12 minutes. A person with basic computer skills does it in under 30 seconds. And almost none of those 12 minutes were spent doing anything on the computer.

Read that again, because it matters for everything that follows. During a rollout, the practice computer is idle more than 96% of the time. It's sitting there, fully booted, with Chrome open, holding gigabytes of memory, waiting for a model somewhere else to finish thinking about what to click next. The computer isn't the slow part. But it's the part you need one of per rollout, and it's awake the whole time.

Each step gets slower than the last

It gets worse as the task goes on. Most agents send the model the whole history so far: every previous screenshot, every previous plan, every previous reflection. So at step 10 the prompt includes steps 1 through 9. The paper measured that by the late steps of a long task, each model call takes up to 3× longer than at the start, purely because the prompt has grown [2]. One task, creating a restricted SSH user, took Agent S2 all 50 of its allowed steps and over 40 minutes. GTA1 finished the same task in 54 steps and nearly twice the time, because it calls the planning model four times in parallel at every step and then calls a judge to pick one.

And there are far more steps than there should be

The second half of OSWorld-Human is a human answer key. Two graduate students worked out, for all 369 tasks, the shortest sequence of actions a competent person would use, and then cross-checked each other [2]. Against that key, the best agents on the leaderboard take 2.7× to 4.3× more steps than necessary. Some of the waste is just inefficiency, but a lot is loops: the planner says "click the blue Open button", the pixel-finding model gives the wrong coordinates, nothing happens, and the agent tries the identical thing again. In failed tasks longer than 50 steps, 66% of steps were spent stuck in such loops. One Chrome task, "set Bing as the default search engine", burned 100 steps, 27 minutes, and $8.47 without succeeding.

"Grouped" means actions a person would do from one look at the screen without needing to look again, like click a cell, type a formula, press Enter. Humans need 3 to 13 steps per task. Agents were taking tens, with budgets of 50 to 100. Every one of those extra steps is another model call, another screenshot, and another stretch of a VM sitting idle.

What one attempt costs in dollars

OSWorld-Human priced it: GTA1 cost an average of $2.43 per task, and 87% of that was the planning model, because it calls that model four times per step and retries up to three times when the output is malformed [2]. That number is from 2025 and from one agent, so let's look at something more recent and broader.

OSWorld-Science, published last week, built 146 tasks on real scientific software: drawing molecules in ChemDraw, analyzing pathology slides in QuPath, running fluid simulations in OpenFOAM, statistics in SAS and R [3]. They ran 12 different models through the same harness, one try per task, with a budget of 100 steps and, for the simulations, 3 hours of wall-clock time. About 1,500 runs total. They logged every token and worked out the cost per task.

Those prices are for the model alone. They don't include the machine. The machine cost is harder to pin down because the papers don't bill it, but we can reason about it. A task budget of 100 steps at the per-step latencies OSWorld-Human measured means a VM is reserved for somewhere between several minutes and an hour per attempt, and for the OpenFOAM simulations, up to 3 hours. During that time it's holding its full memory footprint whether or not anything is happening.

Most of what you pay for produces nothing

Here's the part of OSWorld-Science that stuck with me. They labelled every one of the roughly 1,500 runs by what it left behind [3]:

Only 26% of attempts fully succeeded. 44% produced no deliverable at all, and nearly all of those ran until the budget was exhausted. In training terms, a rollout that produces nothing still has to be paid for in full: full tokens, full VM time, full reset afterward. And the score it hands back is a zero that the training process already could have guessed.

This isn't a complaint about the agents. Failing is the point of practice; you learn from the zeros too. But it means the cost of training is dominated by attempts that run long and end badly, which puts a hard floor under how cheap each attempt needs to be before the whole thing becomes affordable.

The two cheap levers, and what they tell us

OSWorld-Science ran two small experiments that are worth knowing about, because they change the shape of a rollout rather than the model [3]. First, they varied how many recent screenshots the model gets to see. With only the latest one, the agent averaged 52 steps per task and scored 35%. With the last ten, it averaged 22 steps and scored 57%. The agent stopped repeating actions it could no longer remember taking, and gave up on hopeless tasks sooner instead of grinding to the limit. Same model, same tasks, half the steps, more wins.

Second, they turned the model's reasoning effort up. From lowest to highest, output tokens per task grew about tenfold for Claude Opus 5, from 6,000 to 59,000, and the score rose 17 points. Roughly ten times the model cost for a modest gain. For Claude Sonnet 5 the same dial bought three points.

The lesson I take from both: a lot of the cost of an attempt is the attempt being longer than it needs to be. Steps that repeat. Steps that go nowhere. Steps where the model has forgotten what it just did. Anything that shortens a rollout, or lets a doomed one stop early, saves tokens and machine time in equal measure.

Adding it up: the bill for one attempt

Let me put the pieces together into one picture. These are ranges across the three papers, not a single measurement, and the machine side is my reasoning rather than something the papers billed.

What I now think the question is

I started with "what does one attempt cost?" and I think the honest answer is: in tokens, a few dollars, and that's going down as models get faster. In machines, a whole computer, for the whole duration, mostly idle, and that part isn't going down on its own.

The model bill scales with how much the model thinks. The machine bill scales with how many attempts you want to run at the same time. When people say training a computer-use model needs a million computers, that's the second number they mean. If you want 10,000 rollouts in flight, today's tooling asks for 10,000 booted computers, each holding its own copy of Ubuntu, its own Chrome, its own LibreOffice, each started from the same snapshot, each sitting there waiting for a model to decide where to click.

And every one of those 10,000 computers is almost entirely identical to the other 9,999. Same operating system. Same apps. Same starting files. The only thing that differs is what this particular attempt has changed so far, which is usually a handful of files and whatever's on screen.

So the question I'm actually interested in is: how much of the computer needs to exist once per attempt? OSWorld's authors brushed against it when they chose one shared snapshot plus small per-task recipes instead of 369 snapshots. The CUA-Sandbox paper that came out two weeks ago asks it directly, and measures what happens when you share more. That's the next post.

Vocabulary, in case you skipped ahead

• Computer-use agent. An AI model that controls a computer the way a person does: it sees the screen as an image and acts by moving the mouse and typing.
• Rollout. One complete attempt at one task, from a known starting state to a final score.
• Reinforcement learning (RL). Training by trying things and being told afterward whether they worked. Rollouts are the "trying" part.
• Virtual machine (VM). A complete computer, operating system and all, running as a program inside another computer.
• Snapshot. A frozen copy of a VM's entire state that it can be reset to instantly.
• Evaluator. A script that inspects the computer after the attempt and decides whether the task was done.
• Grounding. Turning "click the blue Open button" into exact pixel coordinates. Usually done by a second, smaller model.
• Step budget. The maximum number of actions an attempt may take before it's cut off. 15 in the original OSWorld paper, 50 to 100 in most agents today.

References

1. Xie et al., OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments, 2024. arXiv:2404.07972
2. Abhyankar, Qi, and Zhang, OSWorld-Human: Benchmarking the Efficiency of Computer-Use Agents, MLSys 2026. arXiv:2506.16042. Dataset: github.com/WukLab/osworld-human
3. Dai et al., OSWorld-Science: A Benchmark of Computer Use Agents for Learning and Using Scientific Software, 2026. arXiv:2609.39903
4. Yan, Jiao, et al., CUA-Sandbox: Efficient Environments for Computer-Use Agent Reinforcement Learning, 2026. arXiv:2609.32750

All figures in this post are my redrawings of numbers reported in those papers, cited inline. Where a figure is illustrative rather than plotted from reported data, the caption says so.