Cloud agents

Cloud agents are harnesses in their own right. Moving the same model from your laptop into an ephemeral VM changes the problem completely - the vendor now has to recreate your repository, tools, credentials, browser, dependencies and verification loop before the model can do its best work.

That environment is the product. A local agent inherits the machine you already spent years configuring. A cloud agent starts with an empty box, and an empty box cannot run your tests, reach the private package registry, inspect the app in a browser, or load the instructions that stop it making the same mistake twice. Building that environment reliably for one repository is fiddly. Doing it securely for thousands of concurrent machines is serious engineering.

Why Cursor Takes Gold

Cursor treats cloud execution as part of the harness rather than a separate destination. Its Agents Window can move work between local sessions, isolated worktrees and dedicated cloud VMs; cloud subagents run on their own branches whilst the parent continues locally; and environment snapshots let later agents boot with dependencies ready. The handoff is the feature. You can delegate the long-running leg without leaving the interface where you plan, review and test the result.

That makes concurrency feel useful instead of performative. Ten local subagents fighting over RAM, ports and one working tree is a demo. Cursor spreads the work across isolated environments, then gives each branch a route back to the developer. Its cloud agents also have a terminal, browser and full desktop, so they can use the thing they built and return videos, screenshots and logs rather than a confident paragraph about tests they never ran.

Cursor still has to earn trust around environment setup and data governance, especially in organisations with awkward internal dependencies. Its self-hosted option helps. On product cohesion, however, it leads.

The Runners-Up

Devin takes silver because the remote machine has always been the centre of its product. Each session gets a Linux VM with cloned repositories, installed tools and resolved dependencies, saved as a reusable snapshot - effectively a developer laptop that can be booted on demand. Its embedded IDE, shell and browser make the work inspectable, and its Slack integration gives non-developers a credible way to delegate a scoped task without cloning anything locally.

It loses to Cursor because the product remains a more distinct place to go. Cursor’s cloud agents sit inside a harness developers already use all day; Devin asks the team to adopt Devin as a teammate and workflow. That can be powerful, particularly for support and product operations, but it is a larger organisational bet.

Claude Code takes bronze for capability and reach. Claude’s asynchronous surfaces increasingly let teams hand codebase work off without opening a terminal, and Claude Tag makes the interaction model explicit: product, support and data teams can tag Claude from Slack, let it work against connected codebases, and receive the result in the thread. The direction is compelling. The cloud execution experience is not yet as cohesive or legible as Cursor’s, nor as purpose-built as Devin’s.

Who Needs This Today

Developers with powerful local machines are rarely compute-bound now. Review attention, model limits and task quality usually run out first. Cloud agents still earn their keep for jobs that must survive a closed laptop, work triggered from Slack or an issue tracker, and clean parallelism across isolated branches.

The bigger change is access. Product managers, delivery leads and technical support can ask for a real codebase action without installing a runtime, learning a TUI or keeping a terminal session alive. As model capability expands the size and number of tasks worth delegating, that interaction becomes the default rather than the accessible alternative.

Build the environment before buying the concurrency.