The published number: 76–96% of the time is thinking
The best outside measurement we know of is OSWorld-Human (v2, May 2026). On desktop tasks that a person finishes in about two minutes, computer-use agents take twenty minutes or more, and 76–96% of that time is spent in the planning and reflection calls to the language model (Agent S2; 91–96% for GTA1 including judging). The agents also take 2.7–4.3 times as many steps as the task needs. Two versions of that paper give different step figures, so if you quote it, quote the version.
That number tells you the shape of the problem, not which part of your agent to fix. So we instrumented ours.
Our run: the fast layer was 11%, the "rare" slow layer was 86%
Computron decides each step with a single round trip to a small decision model (Jev, TypeSafe's System One model) and only escalates to a large generative model when the fast layer says it is blocked or is unsure. On a live run against youtube.com on September 22, 2026, with every model call timed, the breakdown was:
Fast decisions: 9 round trips, 0.17–0.57 s each, 2.3 s total, 11% of model time.
Deep-model escalations: 5 calls, 2.6–5.8 s each, 18.5 s total, 86%.
Text helper: 1 call, 0.6 s, 3%.
Four of the five escalations fired on a low-confidence score (0.48, 0.44, 0.42, 0.31). In three of those, the big model answered with a no-op ("find"), which changed nothing on the page, and three no-ops in a row tripped the stall detector, which called the big model a fifth time. At the moment of each of those escalations the fast layer had already chosen wait, which was the right move: the search results were still loading. The gate that was supposed to add intelligence was taking a correct answer from the fast layer and replacing it with a wrong one from the slow layer.
The fix was not a faster model. On low confidence we now ask the same fast layer one more yes/no question about the choice it already made (about 0.26 s) and only escalate on a "no". The same task went from 31.5 s and 15 model calls to 7.6 s and 6 calls, with zero escalations, three runs in a row. "Slow", "inaccurate" and "calls the model too much" were one bug with three symptoms.
The cost nobody had measured: reading the page
After that fix the run was 7.6 s and model time was 1.7 s. Nobody had an account of the other 5.9 s. It turned out that in a month of design notes there was not a single measurement of how long it takes to read a page.
Computron observes a page through the accessibility tree (Accessibility.getFullAXTree over the DevTools Protocol). Measured on September 22, 2026: about 0.05 ms per node, nearly linear. example.com has 15 nodes and reads in 5 ms. A Wikipedia list page has 5,905 nodes, 271 ms. The Wikipedia article on "Computer" has 17,831 nodes and takes 929 ms, of which most is then discarded, because the agent keeps only interactive and landmark rows, capped at 500. On two cold runs with zero generative calls, observation was 63% and 72% of wall-clock time, about three times the decision layer.
Two things we expected turned out wrong. Minimising the window did not slow the tree read (1,054 ms against 931 ms, within noise), even though input and scroll commands slow down 30× in a hidden window. And keeping the accessibility domain enabled did not make reads faster (990 ms against 931 ms). The lesson generalises: a residual with no name does not get suspected. Measure every layer, including the ones that "obviously" cost nothing.
Why a faster model does not fix the shape
Put those two findings together. A model that answers in half the time shortens the 11% slice. It does nothing to the escalations that were firing for the wrong reason, nothing to the 929 ms page read, and nothing to the 2.7–4.3× extra steps. Vision-based agents pay the same tax in a different currency: a screenshot per step is bound to the compositor's frame rate (30× slower when the tab is not visible) and every step carries image tokens. A faster CLI for Claude's computer use, or a "quick mode" in a browser extension, moves the per-step cost; it does not remove the steps. Steps are removed by not deciding at all.
What a replay cache changes
The one lever that removes steps instead of shrinking them is memory. If an agent has already done a task on a page, the second time it should not ask any model what to click. Computron records a successful run as a trajectory (locators, not pixel coordinates; no accessibility node IDs, because those change on every read) and, after two matching successes, replays it with no model calls.
Three rules keep that from being dangerous. A trajectory is only promoted after two independent successes, not one; a single lucky run is not evidence. An irreversible step (submit, delete, pay) replays only when a strict signature of the target matches exactly; on any doubt the run falls back to a cold, model-driven run instead of guessing. And every mismatch, timeout or exception is treated as "different", because a false rejection costs one cold run while a false acceptance clicks the wrong thing on the wrong page.
The honest part: replay is not automatically faster. On the same YouTube task, the replay took 10.3 s against 7.6 s cold, because the front page reorders itself on every visit and the final click fell back to a repair step every time. We do not publish a speed-up multiplier for that reason; the README still says the real-model gains are not yet measured. What replay gives you reliably is zero generative calls on a page that has not changed, and a fail-safe fallback on a page that has.
The checklist we would give anyone whose browser agent is slow
1. Time every model call separately and sum by layer. Do not assume the per-step model is the big one.
2. Time page observation. If you read the full accessibility tree or take a screenshot every step, that is probably your largest line.
3. Look at what the slow path returns. If it returns no-ops, it is not helping; it is replacing good answers.
4. Count steps per task against what a person needs. Extra steps are the only cost no model upgrade will remove.
5. Only then consider a faster model, and measure the before and after at the same success rate. A speed-up with a lower success rate is not a speed-up.
Where Computron is on this
Computron runs in the Chrome you are already signed into, decides each step with one fast round trip, escalates as little as the measurements above allow, and replays what has worked twice. It records total time, model calls and step counts on every run, because a claim without a measurement is not one we want to make. The design notes with all of the numbers above are in the repository.