Lost me even before I realized what was going on. My computer is too slow to handle the tricks they are pulling. I think you are right, but their "cool" things were too slow and made a mess of my screen without having any relation to what I am doing now (because I did it seconds ago)
The words "trail on mouse" instantly reminded me of the Windows mouse trails, that's what I was expecting going into the article.
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.
The article makes the point that on some benchmarks the AIs worked around the UI and then says that sometimes APIs won’t be available. The unwritten implication is that then we’ll be in trouble. But will we? If an API doesn’t exist, is the AI still able to perform the task? That’s not covered in any detail, nor is there any direct comparison between the frontier AI’s performance on these tasks and the model being sold by the company. At some level, I don’t fault the AI for taking the API path if it’s available. In fact, I’m impressed that it found the API and used it correctly. That doesn’t seem like an argument that the sky is falling.
I get the point, but you can't always use the API.
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.
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.
Well, there’s a bigger issue of AIs not doing what we tell them to do, but I think that’s orthogonal to this UI issue. If you want to fault the model for not obeying the prompt or for a poor solution, then fine. My point is, it solved the problem. If the API isn’t there, then that eliminates the API as a solution, but it says nothing about how well the model can solve the UI problem. Perhaps the model can’t solve it. If we really want to benchmark the ability of models to use human UIs to solve problems, then perhaps we need to choose benchmarks that don’t have APIs available such that the model cannot get “creative” in any way and must use the UI as part of the task. More simply, maybe the model isn’t the problem; maybe the benchmark designer is.
> If we really want to benchmark the ability of models to use human UIs to solve problems, then perhaps we need to choose benchmarks that don’t have APIs available such that the model cannot get “creative” in any way and must use the UI as part of the task. More simply, maybe the model isn’t the problem; maybe the benchmark designer is.
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.
Sure, “blame” is a strong word. My point isn’t that anyone deserves actual blame, but just that the models are proving creative. We already know that they will comment out unit tests to make them “pass,” for instance. If we want to focus on a particular skill or behavior, we need the tests to highly constrain the model. If we don’t create our benchmarks like that, shame on us.
Meta: I like that the first comments are not about the model at all but the website's mouse trail. One is in favor and one is against. Sums up society pretty well hahaha.
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.
> - 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.
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.
Throwback to a brief moment when everyone wanted to support IFTTT. If I remember, it ran out of steam because it takes away eyeballs from the actual application (social networks in-particular). The use cases are also rather niche.
Honestly I think we will get something in the middle. A lot of stuff will become API calls, but we will also have a lot of people-facing interfaces, and the need to use them automatically (for QA at the very least least). And then there are games
Hang on, can someone help me understand how these benchmarks work? The post alleges that at least some computer use benchmarks are broken because the model is making direct CDP calls instead of actually interacting with the UI. But the major frontier models' computer use interfaces don't work that way; the model only gets access to a virtual display, and can only provide virtual keyboard and mouse inputs. There are separate browser-use interfaces that offer a CDP connection, but presumably you wouldn't use those if you're specifically designing a computer use benchmark? Is the post just claiming that a lot of impressive demos that people think are of computer use are actually of browser use? I wish it'd been clearer about this.
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.
Thanks, this makes things clearer. Sounds like the idea is that LLMs are competent enough at computer use to bootstrap their way into a terminal or DevTools environment (and from there complete the task using their legitimately impressive scripting skills), but not so good at figuring out how to navigate a UI they've never seen before the way a human does.
Computer use itself is evolving as CLIs and APIs are important again to enable AI use. We'll certainly converge at a happy medium, CLIs, APIs and text for AI, and maybe some form of dynamic interface that the AI builds/adapts on the spot for the exact task you want to execute, on the environment you're at. And of course, good ol' purpose built tools/UIs as we do today, when it makes sense.
that's what a lot of 'a.i' companies miss - unless you've formerly QA devs deployed as Forward Automation Engineers - writing scripts to automate most tasks done by humans in a service economy - by the time the a.i bubble busts it will all about the promise about a.i to transform the economy while it was near achieved.
browser automation, RPA etc can bring us closer to agentic workflows since most software doesn't provide an API.
Agreed and a lot of companies seem to have their head in the sand, just hoping AI agents will magic their way through the legacy
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
I wonder if we will see people building these kinds of computer use systems to augment traditional QA. What I do not have my mind wrapped around at the moment is how agents might reason across the different states of the interface. It seems like it should be possible to build some kind of state machine for this?
Is no benchmark properly sandboxed? It feels like every single the logs are provided for a benchmark run the LLM is cheating in a way that should have been clearly blocked by a sandbox or the harness.
every decade someone rediscovers that the bottleneck was never the model, it was the mouse. we built APIs to avoid this exact problem and then asked the AI to ignore them and click buttons like an intern
You lost me at the annoying trail on mouse movement.
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.
Lost me even before I realized what was going on. My computer is too slow to handle the tricks they are pulling. I think you are right, but their "cool" things were too slow and made a mess of my screen without having any relation to what I am doing now (because I did it seconds ago)
Damn what computer are you using, a 2015 Raspberry Pi?
Pinebook. So not much faster. Runs circles around the machines I grew up on.
The words "trail on mouse" instantly reminded me of the Windows mouse trails, that's what I was expecting going into the article.
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.
You think this blog post is advocating for good UI?
wow reminds me of the Neopets guild pages
[flagged]
The article makes the point that on some benchmarks the AIs worked around the UI and then says that sometimes APIs won’t be available. The unwritten implication is that then we’ll be in trouble. But will we? If an API doesn’t exist, is the AI still able to perform the task? That’s not covered in any detail, nor is there any direct comparison between the frontier AI’s performance on these tasks and the model being sold by the company. At some level, I don’t fault the AI for taking the API path if it’s available. In fact, I’m impressed that it found the API and used it correctly. That doesn’t seem like an argument that the sky is falling.
I get the point, but you can't always use the API.
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.
Well, there’s a bigger issue of AIs not doing what we tell them to do, but I think that’s orthogonal to this UI issue. If you want to fault the model for not obeying the prompt or for a poor solution, then fine. My point is, it solved the problem. If the API isn’t there, then that eliminates the API as a solution, but it says nothing about how well the model can solve the UI problem. Perhaps the model can’t solve it. If we really want to benchmark the ability of models to use human UIs to solve problems, then perhaps we need to choose benchmarks that don’t have APIs available such that the model cannot get “creative” in any way and must use the UI as part of the task. More simply, maybe the model isn’t the problem; maybe the benchmark designer is.
> If we really want to benchmark the ability of models to use human UIs to solve problems, then perhaps we need to choose benchmarks that don’t have APIs available such that the model cannot get “creative” in any way and must use the UI as part of the task. More simply, maybe the model isn’t the problem; maybe the benchmark designer is.
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.
Sure, “blame” is a strong word. My point isn’t that anyone deserves actual blame, but just that the models are proving creative. We already know that they will comment out unit tests to make them “pass,” for instance. If we want to focus on a particular skill or behavior, we need the tests to highly constrain the model. If we don’t create our benchmarks like that, shame on us.
Meta: I like that the first comments are not about the model at all but the website's mouse trail. One is in favor and one is against. Sums up society pretty well hahaha.
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!
We have 2 paths here:
- 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.
> - 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.
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.
Throwback to a brief moment when everyone wanted to support IFTTT. If I remember, it ran out of steam because it takes away eyeballs from the actual application (social networks in-particular). The use cases are also rather niche.
Honestly I think we will get something in the middle. A lot of stuff will become API calls, but we will also have a lot of people-facing interfaces, and the need to use them automatically (for QA at the very least least). And then there are games
Looking how much agents like to use and push to have functional a11y trees, we may accidentally solve accessibility as well
Haha, one day, one day...
Hang on, can someone help me understand how these benchmarks work? The post alleges that at least some computer use benchmarks are broken because the model is making direct CDP calls instead of actually interacting with the UI. But the major frontier models' computer use interfaces don't work that way; the model only gets access to a virtual display, and can only provide virtual keyboard and mouse inputs. There are separate browser-use interfaces that offer a CDP connection, but presumably you wouldn't use those if you're specifically designing a computer use benchmark? Is the post just claiming that a lot of impressive demos that people think are of computer use are actually of browser use? I wish it'd been clearer about this.
Sorry for the confusion, Steelman CTO here.
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.
Thanks, this makes things clearer. Sounds like the idea is that LLMs are competent enough at computer use to bootstrap their way into a terminal or DevTools environment (and from there complete the task using their legitimately impressive scripting skills), but not so good at figuring out how to navigate a UI they've never seen before the way a human does.
Computer use itself is evolving as CLIs and APIs are important again to enable AI use. We'll certainly converge at a happy medium, CLIs, APIs and text for AI, and maybe some form of dynamic interface that the AI builds/adapts on the spot for the exact task you want to execute, on the environment you're at. And of course, good ol' purpose built tools/UIs as we do today, when it makes sense.
that's what a lot of 'a.i' companies miss - unless you've formerly QA devs deployed as Forward Automation Engineers - writing scripts to automate most tasks done by humans in a service economy - by the time the a.i bubble busts it will all about the promise about a.i to transform the economy while it was near achieved.
browser automation, RPA etc can bring us closer to agentic workflows since most software doesn't provide an API.
Agreed and a lot of companies seem to have their head in the sand, just hoping AI agents will magic their way through the legacy
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
I wonder if we will see people building these kinds of computer use systems to augment traditional QA. What I do not have my mind wrapped around at the moment is how agents might reason across the different states of the interface. It seems like it should be possible to build some kind of state machine for this?
You mean all the possible states of the each element of the interface (buttons, forms, content blocks, etc.)?
No, not to that level of detail. There's a higher-level set of states that all other states should be derivable from.
The little pencil effect is a nice touch.
Is no benchmark properly sandboxed? It feels like every single the logs are provided for a benchmark run the LLM is cheating in a way that should have been clearly blocked by a sandbox or the harness.
There's an anecdotal paper 'How We Broke Top AI Agent Benchmarks: And What Comes Next' https://moogician.github.io/blog/2026/trustworthy-benchmarks...
Why is this article based on a chart that has GPT-5.5 and Claude Opus 4.8 as the newest evaluated models? Those are very old now.
There have been massive improvements in computer use in GPT 5.6 and Claude 5.
Unfortunately, mainly because there're only self-reported and partial numbers for the benchmarks that matter the most.
Can AI play OSU? Well finally we have an answer and it’s just barely. Honestly the demo at the bottom is really surprisingly good since it’s realtime
The mouse trail is really annoying! Not a good example of how to do UI.
every decade someone rediscovers that the bottleneck was never the model, it was the mouse. we built APIs to avoid this exact problem and then asked the AI to ignore them and click buttons like an intern
[flagged]
[dead]