Cursor Cloud Agents vs GitHub Copilot Coding Agent for Background PRs

Both of these do the same headline trick: you describe a change, walk away, and a pull request shows up later without your laptop doing any of the work. The question is not whether they can open a PR. Both have been generally available since spring 2026 and both are good at it. The question is where the agent runs, how you launch it, and what happens to the PR when it lands. The short answer: pick GitHub Copilot coding agent when the task begins as a GitHub issue and should end as a reviewed PR under your existing branch protection, and pick Cursor cloud agents when you want a live VM you can attach to, tasks that span more than one repo, and the option to pull the branch down and finish it in your editor. Cost is a wash after the June 1, 2026 billing changes hit both products, so decide on workflow, not price.

Everything below is pinned to versions current as of July 2026: Cursor 3.5 (cloud agents shipped May 20, 2026) and GitHub Copilot coding agent, generally available since March 2026, running on the multi-model harness that can route to claude-opus-4-8, claude-sonnet-4-6, the GPT-5.x / Codex line, and Gemini 3.x. If you are weighing the interactive, in-editor agents instead of the background ones, that is a different comparison, and I covered where Claude Code, Cursor, and Copilot agent mode each win separately.

Same output, opposite centers of gravity

The word “cloud agent” hides the real difference. A Copilot coding agent task is a GitHub primitive. It is born from an issue, it runs inside a GitHub Actions environment, and its whole life is a branch and a PR in one repository. A Cursor cloud agent is an editor primitive that happens to run remotely. It is born from your IDE, Slack, or the Cursor web app, it runs in a Cursor-managed VM with full terminal and browser access, and the GitHub PR is the last step, not the substrate.

That single distinction predicts almost every practical difference below: how you start a task, whether you can watch it work, what it is allowed to touch, and who reviews the result.

Feature matrix

When to pick Copilot coding agent

The work already lives as a GitHub issue. This is the whole design. Assign the issue to @copilot, and the agent picks it up, creates a copilot/* branch, and opens a draft PR that links back to the issue. Triage, backlog grooming, and “good first issue” cleanup map onto this one-to-one. You never open an editor. If you want to dispatch the same task across many repos programmatically, the Agent Tasks REST API turns a POST into a PR, which is the cleanest fan-out primitive either product offers.

You want the PR to obey your existing branch protection. Copilot is deliberately treated as an outside contributor. It cannot push to your default branch, it cannot approve its own PR, and by default GitHub Actions workflows on its PRs do not run until a human clicks “Approve and run workflows”. That is a security posture, not a bug: the agent’s branch could contain a workflow edit that touches your secrets, so a person gates it. GitHub shipped an opt-in setting to skip that approval on March 13, 2026 for teams that want the friction gone, but the safe default is the point.

Your team lives in the GitHub review UI. Required reviewers, CODEOWNERS, status checks, and merge queues all apply with zero extra wiring because the PR is an ordinary PR from an ordinary branch. There is nothing new for reviewers to learn.

When to pick Cursor cloud agents

You want to watch it work, or take it over. A Cursor cloud agent runs in a real VM you can join from cursor.com/agents or straight from the IDE. You see the terminal live, and if it goes down the wrong path you stop it, pull the branch into your local editor, and finish by hand in the same tool you already use. Copilot gives you a session log after the run, not a steering wheel during it.

The change spans more than one repository. Cursor’s multi-repo cloud agent environments landed in 3.4 on May 13, 2026, so one agent can edit a shared library and the two services that consume it in a single task. Copilot’s coding agent is hard-scoped to one repository per task; a cross-repo change becomes three separate issues and three separate PRs you have to sequence yourself.

You start tasks from Slack or Jira, not the issue tracker. Mention @Cursor in a Slack thread and it reads the conversation, spins up an agent, and links a PR back into the thread. The same works from a Jira ticket assigned to the Cursor cloud agent. Copilot can be reached from those surfaces too, but Cursor treats the chat thread as the primary context, which suits “we were just talking about this bug” work better than issue-first flows.

The two configuration files that decide reliability

Neither agent is useful if it cannot build and test your code, and each pins that setup to a different file.

Cursor captures the machine in .cursor/environment.json, committed to the repo so the whole team and every future cloud agent reuse the same snapshot:

// .cursor/environment.json -- Cursor 3.5, July 2026
{
  "snapshot": "auto",
  "install": "pnpm install --frozen-lockfile",
  "start": "pnpm dev",
  "terminals": [
    { "name": "tests", "command": "pnpm test --watch" }
  ]
}

Copilot uses a GitHub Actions workflow, copilot-setup-steps.yml, that runs before the agent starts so dependencies are warm and the network allowlist is in place:

# .github/workflows/copilot-setup-steps.yml -- Copilot coding agent, July 2026
name: "Copilot Setup Steps"
on: workflow_dispatch
jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: pnpm/action-setup@v4
      - run: pnpm install --frozen-lockfile

The Cursor file is a portable snapshot you can boot anywhere Cursor runs it. The Copilot file is a real Actions job, which means it also consumes your Actions minutes and inherits your firewall. Copilot runs behind a default allowlist firewall, and any external service the agent needs at runtime has to be added to that allowlist or the fetch fails. Cursor’s VM has broader default network access, which is more convenient and a larger surface to think about.

The cost picture after June 2026

Both vendors moved to usage-based billing in the same window, so the old “Copilot is cheaper because it is flat” argument is dead.

GitHub switched every Copilot plan to AI Credits on June 1, 2026: Pro is $10/month including $15 in credits, Pro+ is $39 including $70, and Max is $100 including $200, with paid overage beyond that. A coding-agent task burns model credits for the reasoning plus GitHub Actions minutes for the compute, so a long task shows up in two meters. If runaway cost is your worry, the same billing model exposes per-session AI credit spend limits in the Copilot CLI and SDK.

Cursor’s Pro plan is $20/month and includes a $20 credit pool for premium model requests, with cloud agents metered separately by token usage and VM time. There is no separate Actions bill because the compute is Cursor’s VM, not your CI. For a team already paying for GitHub Actions minutes on other workflows, the Copilot task competes for the same minute budget, and that is the one line item people forget to model.

The honest read: at typical volumes the two land close enough that price should not be the deciding factor. Pick on the workflow fit above, then set a spend limit so a stuck agent cannot run up either meter.

The gotcha that picks for you

Two constraints override preference.

The 59-minute cap. A Copilot coding agent task cannot run longer than 59 minutes, and the limit is not extendable because the environment is a GitHub Actions job. A large migration, a slow test suite, or a from-scratch scaffold can hit that wall and leave you a half-finished PR. Cursor’s VM has resource limits but no fixed wall-clock cliff, so genuinely long-running work is safer there.

The single-repo boundary. If your change does not fit in one repository, Copilot cannot express it as one task, full stop. That is not a tuning problem you can configure around; it is the shape of the primitive. Multi-repo work forces Cursor regardless of everything else on the matrix.

If neither constraint bites, the tiebreaker is where you want to spend your attention. Copilot keeps you in the GitHub review UI and asks nothing new of your reviewers. Cursor keeps you in the editor and lets you grab the wheel. Both are legitimate; they are just different jobs.

The recommendation, restated

Reach for the GitHub Copilot coding agent when work originates as issues, must land under your existing branch protection and review rules, and stays inside one repo. Its GitHub-native review flow and REST dispatch are unmatched for issue-to-PR automation, and the 59-minute cap is a non-issue for the small, well-scoped tasks it is best at. Reach for Cursor cloud agents when you want to attach to a live VM and take over by hand, when a task spans multiple repositories, or when tasks start from a Slack or Jira conversation rather than a tracker. Cost is close enough after June 2026 that it should not decide anything; set a spend limit on whichever you choose and let the workflow fit make the call.

Related

• Claude Code vs Cursor vs Copilot agent mode: where each wins in 2026
• How to trigger a GitHub Copilot coding agent task from the Agent Tasks REST API
• How to assign a Jira ticket to a Cursor cloud agent and get a PR back
• Cursor 3.4 adds multi-repo environments for cloud agents
• How to set per-session AI credit spend limits in the Copilot CLI and SDK

Sources

• GitHub Copilot coding agent documentation
• Optionally skip approval for Copilot coding agent Actions workflows
• Customizing or disabling the firewall for GitHub Copilot
• GitHub Copilot is moving to usage-based billing
• Cursor changelog
• Background Agents in Slack