---
title: "Comment by Yunus Emre Vurgun on \"I built desktop control so an agent could test my Chrome extension. Then I benchmarked it against four free tools.\" | Hashnode"
description: "Nice that you scored on what the page ended up showing rather than on what the model claimed; that rule alone makes these numbers more trustworthy than most age"
url: "https://hashnode.com/posts/desktop-control-benchmark/6ad1401cc95ead9bd1583d6e/comment/6ad1b4b435e60559e2c3c67e"
---

[Discussion](https://hashnode.com/posts/desktop-control-benchmark/6ad1401cc95ead9bd1583d6e)

Comment [I built desktop control so an agent could test my Chrome extension. Then I benchmarked it against four free tools.](https://hashnode.com/posts/desktop-control-benchmark/6ad1401cc95ead9bd1583d6e)

[Yunus Emre Vurgun](https://hashnode.com/@yunusemrevurgun)

[Oct 16](https://hashnode.com/posts/desktop-control-benchmark/6ad1401cc95ead9bd1583d6e/comment/6ad1b4b435e60559e2c3c67e)

Nice that you scored on what the page ended up showing rather than on what the model claimed; that rule alone makes these numbers more trustworthy than most agent benchmarks. The Tessa Bright failure is interesting because the tool did exactly what it was told, so a cheap guard could be a pre-action echo for destructive buttons: return the target row's label alongside the element ref and let the model confirm before pressing. It would also be worth reporting the tool-list size as its own column, since 49k vs 3.2k tokens per call probably explains more of the time gap than anything about how the tools actually drive the UI.

[Kuldeep Singh](https://hashnode.com/@ar5en1c)

[Oct 16](https://hashnode.com/posts/desktop-control-benchmark/6ad1401cc95ead9bd1583d6e/comment/6ad1b4b435e60559e2c3c67e#reply-6ad2640b2b262a27afd6508e)

Thanks, this is a good catch. Looking back at the failed run, the click answer only said it pressed "Approve", not whose row that was, so the model had nothing to check before it pressed. Putting the row label in that answer is cheap and I'm adding it.

You're right about the tool list too. It's the main reason for the token gap, so it should have its own column. I'd be careful about time, though. Most of a run is the model deciding, and Cua Driver made 441 calls against 216, so I think the call count explains more of the time gap than the list does. I haven't measured the split.

[Yunus Emre Vurgun](https://hashnode.com/@yunusemrevurgun)

[Oct 17](https://hashnode.com/posts/desktop-control-benchmark/6ad1401cc95ead9bd1583d6e/comment/6ad1b4b435e60559e2c3c67e#reply-6ad3075c771163c8644b6059)

Fair point on call count; 441 vs 216 round trips is a bigger lever than prompt size once the model's thinking time dominates. If you want to separate them cheaply, log time-to-first-token per call: that mostly tracks input tokens, while the gaps between calls track planning, so the two costs show up separately without rerunning anything. Your pc\_do-off run fits that too, since the extra 30% came mostly from Calculator's per-key calls.