What are Cursor cloud agents?

Agents that run in isolated virtual machines in Cursor's cloud with a full development environment: cloned repositories, installed dependencies, secrets, startup commands and network access. They do the same work as the agent in your editor, without needing your laptop to be on.

Were cloud agents previously called background agents?

Yes. Cursor renamed Background Agents to Cloud Agents. Older articles, forum posts and screenshots using the old name are describing the same feature.

How much do cloud agents cost?

They are charged at API pricing for whichever model you select, rather than drawing on a plan's included usage in the way editor requests do. Cursor asks you to set a spend limit the first time you use them. A larger context window increases token use and therefore cost.

Do I need to set up an environment first?

You should. Cursor's own guidance is blunt about it: not setting up a development environment is like not giving your engineers a computer. You can configure one through agent-led setup, a saved snapshot, or a Dockerfile referenced from .cursor/environment.json.

What repository providers work with cloud agents?

GitHub including Enterprise Server, GitLab including Self-Hosted, Bitbucket Cloud, and Azure DevOps. An account admin has to connect source control before anyone on the account can start a run from a repository. You can also start from scratch with no repository at all.

Can my teammates see my cloud agent runs?

Members of the same Cursor team can open a run's URL, but Cursor also checks each viewer's repository access. A teammate has to connect their own source control account under Integrations and have access to the repository. Team membership alone is not enough, and viewing is read-only unless an admin enables team follow-ups.

How many cloud agents can I run at once?

As many as you want in parallel. Because each one has its own VM, they do not contend for your machine's CPU or for a single working copy, which is the main practical reason to use them over local agents.

Can cloud agents run on my own hardware?

Tool execution can, through Self-Hosted Machines. You can also add secrets, restrict outbound domains, and reach private networks with Tailscale or a similar client while still using Cursor's orchestration.

How do I debug a cloud agent run that went wrong?

Cloud agents include a built-in Cursor Cloud MCP that exposes run diagnostics: transcripts, run events, environment details and setup logs. The dashboard also shows which environment and Build each run used, and hovering the repository name on a run page shows the environment for that specific run.

Cloud agents

The same agent, moved off your laptop and into a virtual machine that can actually run your tests. Formerly called Background Agents.

Charged at API pricing
Needs source control connected
Renamed from Background Agents

Checked against cursor.com on 25 September 2026

What changes when the agent leaves your machine

A local agent edits files and asks you to run things. A cloud agent gets its own VM with the repository cloned, dependencies installed, secrets loaded and startup commands run, so it can build the project, run the suite, hit an API and look at the result before it claims to be done. That single difference is most of why cloud agents exist.

The second difference is parallelism. Because each run has its own machine and its own branch, you can have several going at once without them fighting over one working copy. Your laptop does not need to be awake, or online.

The third is the handoff. A cloud run ends in a pull request on a branch, with screenshots, videos and logs attached, which makes it reviewable by someone who was not watching it work.

Where you can start one

Eight entry points, all producing the same kind of run. The one people miss is that Android has no native app and uses the installable web app instead.

Cursor Web
cursor.com/agents in any browser. The fullest interface, and the only place to manage MCP servers for cloud agents.
Cursor Desktop
Pick Cloud from the dropdown under the agent input. The run leaves your machine immediately.
Cursor for iOS
Native iPhone and iPad app. Start a run, read the diff, reply to the agent.
Android
No native app. Open cursor.com/agents in Chrome and tap Install App to get a progressive web app.
Slack
The @cursor command starts a run from a thread and posts back to it.
GitHub and Bitbucket
Comment @cursor on a pull request or issue. The agent picks up the thread as context.
Linear
The @cursor command on an issue, which carries the issue description into the prompt.
API
Start and poll runs programmatically, which is how scheduled and CI-triggered work is wired up.

Before anyone can start a run

A Cursor account admin has to connect source control for the account. This is the step that blocks most first attempts, and it is not something an individual member can do for themselves.

GitHub, including GitHub Enterprise Server
GitLab, including GitLab Self-Hosted
Bitbucket Cloud
Azure DevOps

You need read and write access to the repository and to any dependent repositories or submodules, because the agent clones, branches and pushes. If you have no repository to point at, Start from scratch creates an empty environment instead.

What a cloud agent can do that a local one cannot

Build and test, not just edit
The VM is a real development environment, so the agent can install dependencies, run the test suite and hit services. An agent that cannot run tests cannot close the loop on its own work.
Computer use
Agents can drive the desktop and a browser inside their VM, which is how they verify a UI change rather than asserting that they made one.
Artifacts
Runs produce screenshots, videos and logs attached to the pull request, so the review starts from evidence rather than from a diff alone.
Remote desktop control
You can take over the agent's desktop, click through the change yourself, then hand control back and let it keep working. No local checkout involved.
MCP servers
Both HTTP and stdio transports, with OAuth where a server needs it. Configured per team from the MCP dropdown in cursor.com/agents.
Multi-repo work
One run can span separate frontend, backend, infrastructure and shared-library repositories, make coordinated changes and open a pull request in each repo it touched.

Which of your hooks still run

Cloud agents run command-based hooks from the repository, which keeps formatters, audit scripts and policy checks alive in the cloud. Not everything carries over.

Hook source	In the cloud	Why
Project hooks	Run	.cursor/hooks.json from the repository runs in cloud VMs.
Team and enterprise hooks	Run on Enterprise	Enterprise-managed hooks are applied on top of the repository's own.
User hooks	Do not run	~/.cursor/hooks.json is on your laptop, and the cloud VM has no access to your home directory.
IDE-specific hooks	Do not run	Tab hooks and workspaceOpen have no meaning without an editor window.
Early exploratory turns	Deferred	Hooks start once the agent has a writable environment, not during the initial read-only pass.

Supported hooks include preToolUse, beforeShellExecution, afterFileEdit, beforeSubmitPrompt, subagentStart, subagentStop, preCompact, afterAgentResponse, afterAgentThought and stop.

How billing differs from the editor

This is the part that surprises people. Cloud agents are charged at API pricing for the model you select. You are asked to set a spend limit the first time you start one, and that limit is the only thing standing between an enthusiastic afternoon and a large invoice.

Context window size is a cost lever as well as a capability one. Supported models let you choose it, and a larger window means more tokens read per step, which multiplies across a long run. A cloud agent that takes a hundred steps at a large context window is not slightly more expensive than a short local conversation, it is a different order of magnitude.

The practical habit is to scope cloud runs the way you would scope a task for a contractor: a clear objective, a definition of done the agent can verify itself, and an environment where verification is possible. Runs that wander are runs that bill.

Checked against the Cloud Agents documentation on 25 September 2026.

Frequently asked questions

What are Cursor cloud agents?: Agents that run in isolated virtual machines in Cursor's cloud with a full development environment: cloned repositories, installed dependencies, secrets, startup commands and network access. They do the same work as the agent in your editor, without needing your laptop to be on.
Were cloud agents previously called background agents?: Yes. Cursor renamed Background Agents to Cloud Agents. Older articles, forum posts and screenshots using the old name are describing the same feature.
How much do cloud agents cost?: They are charged at API pricing for whichever model you select, rather than drawing on a plan's included usage in the way editor requests do. Cursor asks you to set a spend limit the first time you use them. A larger context window increases token use and therefore cost.
Do I need to set up an environment first?: You should. Cursor's own guidance is blunt about it: not setting up a development environment is like not giving your engineers a computer. You can configure one through agent-led setup, a saved snapshot, or a Dockerfile referenced from .cursor/environment.json.
What repository providers work with cloud agents?: GitHub including Enterprise Server, GitLab including Self-Hosted, Bitbucket Cloud, and Azure DevOps. An account admin has to connect source control before anyone on the account can start a run from a repository. You can also start from scratch with no repository at all.
Can my teammates see my cloud agent runs?: Members of the same Cursor team can open a run's URL, but Cursor also checks each viewer's repository access. A teammate has to connect their own source control account under Integrations and have access to the repository. Team membership alone is not enough, and viewing is read-only unless an admin enables team follow-ups.
How many cloud agents can I run at once?: As many as you want in parallel. Because each one has its own VM, they do not contend for your machine's CPU or for a single working copy, which is the main practical reason to use them over local agents.
Can cloud agents run on my own hardware?: Tool execution can, through Self-Hosted Machines. You can also add secrets, restrict outbound domains, and reach private networks with Tailscale or a similar client while still using Cursor's orchestration.
How do I debug a cloud agent run that went wrong?: Cloud agents include a built-in Cursor Cloud MCP that exposes run diagnostics: transcripts, run events, environment details and setup logs. The dashboard also shows which environment and Build each run used, and hovering the repository name on a run page shows the environment for that specific run.