What happens when cloud agents are as fast as your local machine?

We’ve spent the last few years obsessing over infrastructure. Over the last few months, we’ve been especially focused on cloud coding agents and on how to make it as easy as possible for developers transitioning from the local machines to continue using them without a problem.

In fact this attempt started internally in our team late last year, somewhere around the time when Andrej Karpathy wrote his “2025 LLM year in review”, article, we’ve basically been hammering at it ever since. To us, coding agents moving to a secure cloud environment seemed inevitable, but the question was why it had not happened yet?

The bottleneck is speed, we realized, and we thought, “What happens when cloud agents are as fast as your local machine?”

When you ping your favourite cloud coding agent in Slack with a task, for example, you don’t expect it to reply instantly. It would take a few seconds, maybe ask a clarifying question, then go away and produce a PR that you or another agent would glance over. We’re now used to equating cloud-based agents with “background agents”, as if it was the same thing. But it’s not.

With Claude Code running on your laptop you wouldn’t work this way. You can of course give it a goal and leave it unattended, and it’ll get it done - but that doesn’t work well for the most important work that you care about most. You’d typically first iterate on designs, plans, different approaches with lots of back-and-forth, look at some prototypes, and most importantly clarify what exactly it is that you want before throwing a swarm of agents at it.

This is the gap that is not (yet) well addressed with cloud agents.

We lose interactivity with background agents as of today!

And interactivity matters a lot, much more than it seems. The main reason is that context-switching is extremely expensive - it’s quite literally the worst possible way to use the human brain. An agent that takes just a tiny bit too long to respond forces you to switch to something else, and every switch costs your brain dearly. It’s a lot like token cache in LLMs actually, very similar dynamic. Except that imagine if cache misses in LLMs made them much slower and much dumber - that’s roughly what context-switching does to the human brain.

Another factor is wasted effort because of extended feedback loops. If you provide feedback to the agent as soon as there’s something to critique, it won’t waste any time. But if you only share feedback when the entire project is done, chances are that 90% of the work will be wasted and will need to be redone. So working with a slower agent is not merely slower proportionally to speed - the time to project completion grows non-linearly.

While models weren’t good enough we got used to agents other than those running on our laptops being too slow to be interactive - so we keep using them in fire-and-forget fashion. But all this does is grow work in progress for no reason, and overloading our brains. Full autonomy isn’t the answer either. As soon as full autonomy at some level is achieved, it stops being a concern for humans - it’s just done fully automatically, without any need to interact with it at all. You’d just switch your attention to a level above where AI still needs steering occasionally. And there, attention management matters again.

@Computer and how it happened

Since launching OpenComputer about seven weeks ago (after a few months in alpha), we kept seeing very similar patterns: many users were building cloud coding agents to use from Slack, and most were hacking them together on our agent API.

This prompted us to build @Computer, initially as a template. It would soon become our daily driver for writing code internally. But given its interactivity and speed, we decided to lead with it and benchmark it too, so users can easily try it in Slack.

Here’s what that looked like:

@Computer vs local Claude Code

Our first test was to compare an OpenComputer cloud session with a local Claude Code session side by side. In order to perform this test we built a CLI client for OpenComputer.

In a few rounds of tests of side by side comparison with the same task we saw that OpenComputer was either as fast as local Claude or faster. This test was run on a local MacBook Pro M2 machine. One of the surprising advantages of having a cloud session is that it is likely closer to the inference provider or colocated with it, which (to our surprise) also leads to sometimes faster than local speeds. In this video the left is Claude Code running on the local Mac machine, the right is opc running in a remote cloud session. Both have been given the same task in the same repo for a fair comparison.

@Computer vs other cloud coding agents

The second comparison we did was OpenComputer vs other cloud coding agents such as Devin (& friends). In order to test the speed of a task we created a simple test where we give an agent access to 4 different repos and gave each agent the same task:

@<Agent> bump zod to the latest version in sb-config-loader, sb-api-schema, sb-form-validator and sb-event-parser, run the checks, and open a PR in each.

The repo is public here: https://github.com/diggerhq/speedbench

For each one of these the prompt was shared in Slack, we measured the time from the prompt (Slack message timestamp) until the 4 PRs appeared. The time from initial message until PR appearing in GitHub is the elapsed time.

For each provider we did 5 rounds of this test. After each round we closed the open PRs and started over. In some cases the providers needed an additional nudge to run the benchmark test since they would refuse the task given that a closed PR exists (memory interference).

We measured the median across 5 rounds and recorded the results as shown below:

You should try it for yourself

Today we’ve opened access to @Computer via a public beta. You get 3 days/600 work minutes free to try it out and can bring your subscription with you.

Go and try it out and let us know what you think!