Cursor Cloud Agents vs Local Agents: A Practical Guide

At Cursor, cloud agents now create more than 60% of the pull requests merged internally, according to Cursor’s September 2026 announcement. That’s a vendor-reported throughput figure, not an independent audit of code quality. Still, it shows why Cursor Cloud Agents vs local agents is now an operating-model decision rather than a minor IDE preference.

The short version: local agents suit ambiguous work where you want tight feedback and local context. Cloud agents suit bounded tasks that can proceed independently and return a verifiable result.

What actually differs between Cursor Cloud Agents and local agents?

The execution location changes. The underlying agent loop—the repeated plan, tool call, and response cycle—remains in Cursor’s cloud for Cursor Cloud Agents.

Cursor documents three Cloud Agent runtimes: Cursor-managed Cloud Agents, My Machines, and Self-Hosted Pool. In all three, the agent loop runs in Cursor’s cloud; only the location of tool-call execution changes. A local agent is different: you run the interactive session on your own machine, close to your checkout, editor, and local development context. The agent may still use cloud inference, so “local” shouldn’t be read as “fully offline.”

Cursor-managed Cloud Agents run on isolated Ubuntu virtual machines. They clone the repository, install dependencies from a Build snapshot defined in .cursor/environment.json, and generally open a pull request when finished, according to Continuum’s Cloud Agent guide. That’s a clean boundary for a well-defined change: the agent gets an environment, performs the work, and leaves evidence for review.

A local agent keeps you in the interactive loop. You can redirect it, inspect intermediate state, and respond to a failed assumption immediately. The trade is availability and isolation: the session depends on your machine, and you receive less infrastructure offloading. Neither mode is universally better; the task boundary determines which cost matters more.

Which runtime should you choose for a given task?

Choose local execution for ambiguity, and choose cloud execution for jobs you can specify and verify. Cursor recommends managed Cloud Agents as the default and says that path is sufficient for more than 80% of customers. Its guidance is equally direct: local agents fit ambiguous work requiring tight review and local context, while cloud agents fit bounded, independent tasks with clear handoffs and strong checks.

Cursor Cloud Agents vs local agents can be summarized in the execution model and audience table below. Self-hosted execution belongs in the comparison because moving tool calls onto your hardware creates a third choice rather than making an agent completely local.

Option	Pricing	Execution and features	Best fit
Local agent	—	Interactive execution with your checkout, tools, and immediate review	Ambiguous implementation, rapid iteration, architecture-sensitive changes
Cursor-managed Cloud Agent	Selected-model API pricing; included usage is consumed before on-demand charges, per Cursor’s billing clarification	Isolated Ubuntu VM, cloned repository, Build snapshot, dependency installation, pull-request output	Bounded work that can run independently with strong checks
My Machines	No separate execution fee was documented; model usage and your infrastructure still apply, per Istar’s cost review	Tool calls execute on one user-controlled laptop or VM while orchestration stays in Cursor’s cloud	Individual workflows requiring private-network access or custom tools
Self-Hosted Pool	No separate execution fee was documented; model usage and fleet operations still apply, per Istar’s cost review	Organization-managed worker fleet for centralized routing and infrastructure ownership	Enterprise workloads requiring controlled hardware or network placement

Cursor reports that Self-Hosted Machines can execute across eight backends: AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel, and E2B. Team Pools require Enterprise, while My Machines is available to individuals on paid plans, according to Istar. That distinction matters: a useful personal runtime doesn’t automatically translate into a manageable production fleet.

Does self-hosting keep code inside your network?

No. Self-hosted execution can keep the repository checkout, build artifacts, and machine-local credentials on your infrastructure, but it doesn’t make the system air-gapped. The widely held technical view is that workers send tool outputs—including file contents, terminal output, diffs, screenshots, and local Model Context Protocol results—to Cursor for inference, as detailed in Start Debugging’s architecture analysis.

This is where Cursor’s “self-hosted” label needs careful reading. In the official self-hosted-machine announcement, only execution moves. The agent loop, inference, and planning remain in Cursor’s cloud, and tool outputs may contain code. You gain control over the machine and network path used to execute commands. You don’t gain a guarantee that source text never reaches Cursor.

Privacy Mode addresses a different question. Cursor’s pricing and privacy documentation says code data isn’t used for training by Cursor or its model providers. It doesn’t stop the transfer of data to Cursor’s cloud for inference. Training use and data transfer are separate risks, and a security review has to evaluate both.

Managed Cloud Agents can also have stronger default guardrails. Cursor says its hosted environments include per-agent isolation, secret redaction, network controls, and signed commits. A self-hosted worker may be inside your firewall while still transmitting sensitive tool results outward. For teams that need private execution, I recommend reading our analysis of the real costs of Cursor Cloud Agent environments before assuming that infrastructure control is equivalent to data isolation.

How do local and cloud agent costs compare?

The model bill doesn’t disappear when execution moves onto your hardware. Self-Hosted Machines don’t reduce Cursor inference costs; you still pay the model usage and subscription charges while also paying for and operating the machines, containers, or clusters, according to Istar’s September 2026 review. That makes self-hosting an operational choice, not a discount mechanism.

Cloud Agents draw from included model usage first, then move to on-demand charges when that allowance is exhausted. On-demand billing must be enabled before Cloud Agents can run. Cursor corrected an earlier support response that had incorrectly said Cloud Agents skipped included usage, as shown in the April 2026 forum clarification. That sequence matters because the subscription and inference layers are separate meters.

There’s also a setup-cost wrinkle. Environment setup runs on a fixed model, Opus 4.8, regardless of the model selected for normal work. The first few setup runs are free, but later messages in the setup conversation are billed at that model’s rate, according to Cursor’s forum response. If a setup chat continues far past environment creation, the model pinned “for setup reliability” becomes a cost assumption you need to inspect.

For a 50-developer scenario, Cursor’s documented prices produce $24,000/year for Teams Standard: 50 × $40/user/month × 12. Teams Premium produces $72,000/year: 50 × $120/user/month × 12. Those are base subscription figures, with inference overages still possible. Our separate Cursor Cloud Agents enterprise cost analysis digs into why usage mix can matter more than the tier label.

How do persistent Projects change the local-versus-cloud decision?

Persistent Projects favor cloud execution because they are designed to continue after you close your laptop. Cursor’s September 10 Projects release adds a coordinator agent that plans work, delegates to subagents, preserves context over months, and supports recurring work without another manual prompt, per the Projects changelog. The coordinator can delegate to thousands of parallel subagents.

That changes the unit of evaluation. With one local coding session, a bad result may cost an hour of attention. With a persistent coordinator, an incorrect decomposition can fan out across many pull requests before anyone notices the premise is wrong. Local execution becomes more valuable at the points where a human needs to test assumptions, inspect private state, or intervene before work multiplies.

The throughput evidence is promising but incomplete. Cursor reports that new Projects users merge 30% more pull requests, while engineers using Projects as their primary workflow merge six times as many. Those figures aren’t independently audited, and AI Insiders notes that they measure PR throughput rather than bugs, review time, reverts, or production stability.

So don’t treat more merged PRs as proof of better development. The background-to-cloud agent transition makes asynchronous execution easier, but durable coordination also requires stronger acceptance tests and review criteria. A cloud coordinator can work while you sleep; your controls determine whether it should.

What decision framework should an engineering team use?

Classify the work before choosing the runtime. A task with unclear architecture, sensitive local context, or several unresolved design questions belongs with a local agent. A task with a named scope, target files, test criteria, and a clean pull-request handoff is a cloud candidate. A task needing private-network services or specialized hardware adds self-hosted execution to the requirements list.

Then trace the complete data path. Don’t stop at “where does the command run?” Ask which files the agent reads, what appears in terminal output, whether screenshots are generated, what local tools return results, and which data must leave the network for inference. A laptop under your control can still expose code through returned tool results. Architecture beats labels here.

Finally, assign an owner to cost and quality. Cloud usage should have an allowance owner, a defined on-demand policy, and a review of the setup conversation’s model. Projects should have merge gates tied to tests and production signals, not only PR volume. Cursor Router is also rolling out to Teams and Enterprise first, with Individual plans following months later; Enterprise starts with it off and requires admin opt-in, per Cursor’s pricing documentation. Model routing is useful, but it isn’t a substitute for governance.

A practical pilot doesn’t need a large benchmark. Select one bounded cloud task, one ambiguous local task, and one private-network requirement if you have one. Record review effort, failures, data movement, infrastructure time, and model spend. That small test will expose workflow assumptions faster than a broad rollout.

What should you standardize on now?

Default new agent work to the least complex runtime that satisfies its actual constraint. Use local execution when judgment and interactivity dominate. Use managed cloud execution for independent, checkable work. Add self-hosted workers only when private network access, fleet control, or specialized hardware justifies the extra operating burden.

Then set a promotion rule: a runtime becomes the team default only if it beats the simpler option on reviewed outcomes, not demo speed. Run that comparison on your highest-value task shape, then ask whether the remaining uncertainty is code quality, data handling, or cost. That’s the question your rollout decision should answer.