The ceiling nobody talks about
Local agents are fast to start. You open Cursor, describe the task, and the agent starts editing files. Feels like a superpower β until you try to run two agents at once, or ask one to verify that the login flow actually works after the fix.
The problem isn't the model. It's the environment. A local agent shares your CPU, your filesystem, your running dev server. It can write code, but it can't use the software it just wrote. It hands you a diff and says "should be good." That's where the ceiling is.
Cloud Agents are Cursor's answer to that ceiling.
What actually changed
Each Cloud Agent runs in its own isolated VM with a full desktop environment. Not a container. A full VM β with a browser, a terminal, a desktop, and the ability to start servers and click through UI like a human developer would.
The artifact β the video recording of the agent clicking through the app β is the part that changes the review experience. You don't need to check out the branch, run the app locally, and reproduce the scenario. You watch the agent do it.
Local Agent vs Cloud Agent
| Capability | Local Agent | Cloud Agent |
|---|---|---|
| Write and edit code | β | β |
| Run terminal commands | β | β |
| Run multiple agents in parallel | β (resource conflict) | β (isolated VMs) |
| Start a dev server and test UI in browser | β | β |
| Record video proof of changes working | β | β |
| Auto-fix CI failures on the PR | β | β |
| Keep running when you close your laptop | β | β |
| Use MCP servers (team-level) | Per-user config | β (team-shared) |
The number that matters
Cursor published one internal metric alongside this release: more than 30% of the PRs they merge internally are now created by Cloud Agents running autonomously in cloud sandboxes.
That's not a benchmark. That's a signal about how the team's workflow changed. The shift they describe: instead of breaking tasks into small chunks and micro-managing agents, they now delegate more ambitious tasks and let them run on their own.
The developer role moved from implementation to direction + review.
The self-hosted angle: running agents on your own infrastructure
After reading the release post, I went down the docs rabbit hole and found something that wasn't in the headline: a Self-Hosted Pool option.
By default, Cloud Agents run on Cursor's infrastructure. With Self-Hosted Pool, you bring your own compute β a K8s cluster, for example β and Cursor routes agents there instead. I set this up myself on a project with stricter data requirements, and the setup looks like this:
The Devbox image is the piece most people skip over. Standardizing the environment means the agent and every developer on the team run against the same image β no more environment mismatch, no more "it works on my machine but the agent can't reproduce it."
For teams with data sovereignty requirements or internal security policies, this isn't a workaround. It's a supported deployment mode, and it changes the calculus on whether you can adopt Cloud Agents at all.
Should your team adopt this now?
The honest assessment: Cloud Agents are ready for well-scoped feature work, bug fixes, and UI regression checks. They're not yet reliable for tasks with ambiguous specs or those requiring deep cross-system reasoning without good MCP tooling in place.
What's next (per Cursor)
Cursor's stated direction is "self-driving codebases" β agents that merge PRs, manage rollouts, and monitor production without human initiation. The near-term focus is coordinating work across many agents and training models that improve based on past runs.
The infrastructure is already being built by teams who understand what's coming. The question for the rest of us is when to start treating agent-generated PRs as a first-class part of the development workflow β not an experiment, but a process.