You can't solve computer use by ignoring the interface
steelmanlabs.com
steelmanlabs.com
You advocate for good UI and immediately make some crap that makes it hard to read/use your site. It's kind of ironic.
Please stop messing with: selection, mouse cursor, copy/paste, etc.
But honestly, I really liked whatever you call this type of trail. Not sure this was the intent, but I used the trail to trace under the lines as I reading them which helped me pay attention to the text a bit better.
100% agree with you on messing with selection and copy/paste though.
1. Presumably you want to trust your agent to do no shady sheningans behind your back when you give it a simple task 2. Sometimes it just doesn't work.
https://osworld-v2-monitor.xlang.ai/task/tasks/068
Does this look like an efficient way to solve the task to you? 500 steps of fiddling with a JS injection, followed by hacking the task.
The funniest part is that it needs to achieve a score of 100, but puts 150 "just in case". I don't think I want it to take the same approach when e.g. fixing a customer's balance.
That's a valid point, yet it's hard to blame authors of OSWorld and ALE. They created an env for benchmarking long horizon task completion to be as close to real computer as possible. And for this goal CLI/API access is generally useful, yet when the model not defaults to it for the majority of subtasks.
There're benchmarks that would measure UI literacy (Webgames Benchmark is one). But they are far from the task we want to benchmark in the end.
On the model. Really cool that it can act every 70ms. That's more than 10x faster than TTFT in most inference APIs. It HAS to be a local model. No idea which family or which one it is or what hardware it runs in. These would be nice details to tease!
- either evolve our UI systems for computers and let them operate efficiently, i.e. converting everything to API calls . Frontier labs are pushing for this, starting with the Chrome plugin that Claude Cowork mandates.
- or make AI systems use the screen like humans do - what the article is arguing for
Both of these paths are possible. One of them is much more efficient than the other in the long term. Another one may be inevitable.
Yea, hasn't worked so far, devs and orgs have been pushing for APIs ages, same with structured data, eg schema.org
The third option is agent to agent communication, mcp, etc.
OSWorld (even the old ones, v1 and verified) runs the model in a full linux VM. And using the terminal is allowed. The models are given tools that provide a subset of possible UI actions. They then use them to open the terminal and script their way to solutions.
Even when this is prohibited, models hack their way around restrictions. Like in OSWorld v2 Claude Opus 4.8 inserts some JS in the browser search bar to execute it instead of playing the Chrome dinosaur.
WebArena is better in that regard because it doesn't allow to use the terminal. But it's worse in another regard: only allows limited actions and the tasks are only such that an agent can win by using a few pre-defined actions (click, scroll, new tab, etc). Which is a tiny subset of what real browser use is, in my opinion.
browser automation, RPA etc can bring us closer to agentic workflows since most software doesn't provide an API.
But I don't think RPA is the way. Or at least, not in the current state. I think AI agents with proper computer use are what RPA should be. Usual RPA is too brittle and maintaining it often requires more work than just doing the work
There have been massive improvements in computer use in GPT 5.6 and Claude 5.