I built desktop control so an agent could test my Chrome extension. Then I benchmarked it against four free tools.

Good question. I haven't tested pc_do on its own yet, so I can't say for sure how much of the speed comes from it. My guess is most of it, because the model spends far more time thinking between calls than the tool spends clicking.

And yes, doing a whole form in one go did break once, on that exact form. The next keys went in before the dropdown had opened, so one field never got set, but every step still said "ok". That was my bug, not the model's. It waits for the menu now, and the form passed every run in the latest benchmark.

Running the same tasks with pc_do switched off is a good idea. I'll try it and share what I find.

Ran it. Same tasks, same model, with pc_do switched off so every click is its own call.

Both versions passed every run, including that seven-field form, so doing a whole form at once didn't cause extra mistakes. Without it, runs took about 30% longer and made twice as many calls. Most of that was Calculator, where every key is its own button. On web pages the difference was small.

So pc_do is part of the speed but not all of it. The rest seems to come from how heavy each call is.

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.