What is a background agent? The per-task cloud loop, explained

The definition, and why the term is confusing

A background agent is a coding agent that runs a task on infrastructure that is not your machine, while you get on with something else, and finishes by handing you a reviewable artefact. In practice that artefact is almost always a branch with a pull request on it, because a pull request is the one interface every engineering team already knows how to receive work through.

The word "background" is doing two jobs at once, which is the source of most of the confusion. It means asynchronous (you are not watching it) and it means elsewhere (it is not on your laptop). Those two properties usually travel together but they are separable, and separating them is the fastest way to make sense of the category.

Row three is the one people forget exists, and it matters because it has the properties most developers actually want: nothing to reconfigure, your secrets already present, and no per-task cold start. Row four is a different product category that keeps getting compared to row two because both are "an agent that runs while you sleep".

Every vendor renamed it, which is why the search results conflict

If you searched for this term and got contradictory answers, that is not you. All three products changed their names inside a year, and the documentation moved with them while the third-party writing did not.

The GitHub row is the funniest and the most useful: the documentation page reachable at the coding-agent path refers to the product as "Copilot cloud agent" throughout. Both names are therefore live, both are searched, and any page that insists only one is correct is wrong about the product it is describing.

The practical consequence is that most of what ranks for "cursor background agent" describes the 2025 feature, which had a different entry point, different billing, and a different answer on Privacy Mode. Check the date on anything you read about this, including this page.

Cursor background agents, now Cloud Agents

Cursor’s implementation is the most fully built out, and it is the one people mean when they type "background agent" into a search box (the term carries around 590 searches a month at a keyword difficulty in the teens, which tells you how young the category still is).

A Cloud Agent runs in an isolated Ubuntu VM in Cursor’s cloud with your repository cloned, dependencies installed, secrets injected, and startup commands run. Cursor does not publish CPU, memory, or disk figures and describes the default VM profile as having limited memory and CPU; custom resources exist as an Enterprise feature. Assume a modest box rather than a build server.

• Setup lives in .cursor/environment.json and is baked into a Build, a bootable snapshot, so agents start ready rather than installing dependencies on every run. Builds carry no separate charge.
• You can start one from nine surfaces: the desktop Agents Window, cursor.com/agents, the iOS app, Slack, GitHub, Bitbucket, Linear, the API, and the CLI by prefixing a message with &.
• An account admin must connect source control first, with read-write repository privileges so the agent can push a branch. On a work account this is the step that blocks you and not one you can do yourself.
• Billing is the selected model’s API pricing, drawn from your included allowance first.
• Privacy Mode is fine; Privacy Mode (Legacy) is not, because a cloud agent has to store code and environment data while it runs.
• The machine is ephemeral. Commit constantly, because uncommitted work does not survive a VM reset.

The full walkthrough, including the failure modes and the concurrency limits, is in the Cursor background agents guide.

Codex cloud tasks

OpenAI’s version is the most cleanly separated from an editor. Codex runs in two places: a CLI on your machine with granular approval controls, and cloud tasks that run server-side on OpenAI infrastructure. The cloud half is the background agent.

The documentation describes tasks running in "isolated cloud environments" where you can "work in parallel". You configure an environment once with its dependencies, tools, variables and setup steps, then pick it when you describe a task. The task returns a summary and a diff for you to review, and from there you can ask for follow-up changes or open a pull request. Agent internet access is a configurable property of the environment rather than an unconditional default, which is the detail teams with a security review care about most.

Where Codex cloud tasks fit best is batch work with a clear boundary: dependency upgrades, expanding test coverage, style migrations, and bug fixes described precisely enough that success is testable. They fit worst where the task depends on state that is not in the repository, which is the same constraint every product in this section shares.

GitHub Copilot cloud agent

GitHub’s implementation has the least setup of the three because it reuses infrastructure your repository already has. The agent "runs in a secure, ephemeral development environment powered by GitHub Actions", where it explores the codebase, makes changes, and runs your tests and linters.

You start it by assigning work: from the agents panel, from a GitHub issue, from Visual Studio Code, by mentioning @copilot in a pull request comment, or on a schedule. It pushes commits to a draft pull request as it goes, and the session logs are visible while it works, which is the best progress interface of the three.

• Availability: "Copilot cloud agent is available for all paid Copilot plans." Business and Enterprise subscribers need an administrator to enable it.
• Billing: it consumes GitHub Actions minutes and AI credits. Within your included minutes and credits there is no additional charge, which means the cost lands in a budget line your organisation probably already tracks.
• The environment is your Actions environment, so whatever your CI can already reach, the agent can broadly reach too. That is a convenience and a scope question at the same time.

The Actions billing model is genuinely different from the other two and worth understanding before you scale it up. Cursor and Codex meter inference; Copilot meters inference and machine time separately, and on a busy repository the Actions minutes are the line that moves first.

The four things every background agent needs from your repository

Different vendors, same four prerequisites. If a background agent is underperforming for you, it is nearly always one of these rather than the model.

A repository that satisfies all four is a repository a new human hire can also start work in on day one, which is why teams that already invested in onboarding get results from background agents faster than teams that did not. The agent is not the variable.

How Grok Bot differs, and why the comparison keeps happening

Grok Bot launched on 11 August 2026 and gets compared to background agents constantly, partly because both run remotely and partly because since 21 August it is bundled with Cursor Pro+ and Cursor Teams plans, so a lot of developers now own both without having chosen either.

They are different shapes. A background agent is a task runner: you give it a job, it gets an ephemeral machine, it returns a diff, the machine disappears. A Bot is a persistent teammate: xAI documents that "all of your Bots use the same persistent cloud computer", that they "share files, browser sessions, and app logins", and that named Bots "keep memory, files, browser sessions, and preferences across turns". Nothing is discarded at the end of a task, which is the point.

The head-to-head with the closest product on each side is covered in Grok Bot versus Cursor background agents, and if what you actually want is xAI’s coding agent rather than its teammate product, Grok Bot versus Grok Build sorts out that confusion.

The fourth option: the same agents, on your own machine

Every constraint in the section above comes from the machine being somewhere else and starting empty. Running the same agents on your own hardware removes the constraint rather than working around it, and the asynchronous half of the value survives intact if you can drive the session from your phone.

That is what a workbench like Continuum does: it starts Claude Code, Codex, Cursor, Grok, Gemini, or OpenCode sessions on your Mac or Linux box, each in its own git worktree so parallel work does not collide, and gives you iPhone and web control of a session that is executing on your desk. The repository is already cloned, the toolchain is already installed, the environment variables are already there, and the branch you are half way through is visible to the agent because it is on the same disk.

The last row on the honest side of the ledger is row six. If you have no machine that stays awake, a cloud background agent is simply better for you, and no amount of argument changes that. If you do have one, the cloud version is solving a problem you do not have while charging you for a machine you already own.

Which one to use, by situation

One habit worth adopting whichever you pick: write the task the way you would write it for a contractor with repository access and no context. Name the files, state the acceptance test, and say what not to touch. Every one of these products improves more from that than from a model upgrade, and it is free.

Questions people ask

Keep reading

Continue through Agentic coding with Do AI agents need their own computer? The managed-VM pattern, examined.