GitHub Copilot Cloud Agent vs Agent Mode

GitHub Copilot Cloud Agent vs Agent ModeGitHub Copilot Fundamentals9Beginner → Intermediate/github-copilot/getting-started/coding-agent-vs-agent-mode/

There are two things called “the Copilot agent”, and the confusion between them is not the reader’s fault — GitHub renamed one of them.

This lesson resolves the terminology, compares the two properly, and gives you a decision rule for which to use. It is the most strategically useful distinction in Cluster 1, because choosing wrong wastes either your attention or a round trip.

Key takeaways

• Agent mode runs in your editor, on your working tree, while you watch.
• The cloud agent runs on GitHub’s infrastructure and returns a pull request.
• The difference is not capability — it is where the work happens and whether you are present.
• The cloud agent opens exactly one pull request per task, and sessions are capped at 59 minutes.
• Neither removes review. They change what you review and when.

The two agents

Agent mode is an in-editor feature. You give it a goal, it works in your workspace, it asks permission before running commands, and you watch the diff appear. When it finishes, the changes are in your working tree, uncommitted.

The Copilot cloud agent is an asynchronous service. You assign it a task from GitHub.com, from an issue, from VS Code, from GitHub Mobile, or by mentioning @copilot on a pull request. It runs in its own ephemeral development environment, powered by GitHub Actions — not on your machine. It researches the repository, plans, implements, commits, and opens a pull request for review.

The distinction is not about how clever each one is. It is about presence: agent mode assumes you are watching, the cloud agent assumes you are not.

Full comparison

What the cloud agent can and cannot do

Some constraints are worth knowing before you plan around it.

One pull request per task. GitHub is explicit: the agent “can open exactly one pull request to address each task it is assigned.” A task that naturally splits into three pull requests is three tasks.

One repository at a time. It cannot work across multiple repositories in a single task. Cross-repository changes need coordinating yourself.

GitHub-hosted repositories only. It works only with repositories hosted on GitHub.

Fifty-nine minutes. Sessions have a hard maximum duration. A task that cannot finish in that window will not finish.

Branch protection applies. Incompatible branch protection rules or rulesets can block it entirely. Administrators can add Copilot as a bypass actor where that is appropriate — which is a decision to make deliberately, not a workaround to apply reflexively.

Third-party coding agents

A third category exists and is worth naming so it does not become a fourth source of confusion.

Third-party coding agents are external agents that work alongside the Copilot cloud agent, under the same security protections. They are currently in public preview, and are excluded from Copilot Free and Copilot Student while being available on every paid plan.

For the purposes of this lesson, they behave like the cloud agent — asynchronous, returning a pull request — rather than like agent mode. The decision rules below apply to them in the same way.

Use agent mode when…

• You are already in the code. The context is in your head; walking away to write a task description loses it.
• The task needs steering. You expect to say “not like that, like this” — which is cheap in agent mode and expensive as a round trip.
• You want to see it happen. Watching an agent work through a codebase teaches you things about the codebase.
• The task is exploratory. You are not certain what the change should be, and expect to change your mind.
• You need it now. Agent mode produces a diff in minutes; a pull request is a longer loop.
• The work must not leave your machine — for example, in a repository that is not on GitHub.

Use the cloud agent when…

• The task is fully specifiable up front. If you can write the whole brief and walk away, that is exactly its shape.
• You want to do something else meanwhile. This is the actual value: it is not faster, it is parallel.
• The work is self-contained — one repository, one coherent change, one pull request.
• It starts as an issue. Assigning an existing, well-written issue is the smoothest entry point, because the specification already exists.
• You want the review to happen in the normal place. A pull request goes through your existing review process, CI and checks, exactly like anyone else’s.
• It is tedious and well-understood. Dependency bumps, mechanical migrations, adding a missing test file — work you would delegate to a person if one were free.

Use neither when…

Both agents share the same weak spots, and reaching for a different one does not help:

• Requirements are still being decided. An agent will implement one interpretation with total confidence. You will get an answer to a question you had not finished asking.
• The correctness is subtle. Concurrency, floating-point precision, cryptography, authorisation logic, anything handling money. Plausible output is the failure mode, and both agents produce plausible output.
• You cannot review the result. If the code is beyond your ability to evaluate, an agent has not helped you — it has produced something you must either trust blindly or discard.
• The change has consequences outside the repository. Database migrations against real data, infrastructure applied to live environments, anything irreversible.
• The task is trivial. Writing the brief takes longer than making the change.

Working with each

A well-scoped agent mode task

Replace the bare except: blocks in payments/ with specific exception types.

Preserve the existing log messages exactly. Do not change any function signature. Run pytest tests/payments/ and fix anything that fails — but do not modify the tests. If a test looks wrong, stop and tell me.

A well-scoped cloud agent task

Add pagination to the GET /api/orders endpoint.

• Accept page (default 1) and per_page (default 25, maximum 100) query parameters.
• Return 400 for out-of-range values, using the existing error response shape in app/errors.py.
• Include total, page and per_page in the response body alongside the existing items array.
• Follow the pagination pattern already used by GET /api/customers.
• Add tests in tests/api/test_orders.py covering defaults, an explicit page, the maximum, and an out-of-range value.
• Do not change the response shape for existing callers who pass no parameters.

The difference in the second is that it answers every question the agent might otherwise guess at: defaults, limits, error shape, an existing pattern to follow, the tests expected, and what must stay backwards compatible. Nobody is there to answer a follow-up, so the brief has to be complete.

Reviewing what each produces

The review differs because the artefact differs.

Agent mode hands you an uncommitted working tree. Review it as a diff, not in the editor — reading files in place makes it easy to see what you expected rather than what changed. Pay particular attention to files you did not ask about, since a change outside the stated scope is the one least likely to get read.

The cloud agent hands you a pull request, which means your existing process applies: CI runs, required checks apply, and review happens where review always happens. That is a genuine advantage — the safeguards are already in place.

It is also a genuine risk, because a pull request from an agent looks exactly like a pull request from a colleague. It has a title, a description and a clean commit history, and all of that is generated. The presentation carries no information about correctness.

Which is “better”?

Neither. They solve different problems, and a team that uses Copilot well uses both:

• Agent mode for the work in front of you, where your attention is already committed and steering is cheap.
• The cloud agent for the queue of well-understood work you have not got to, where your attention is the scarce resource.

The mistake is not choosing wrong once. It is defaulting to one because it is familiar — either burning your attention on tasks that could have run without you, or writing elaborate briefs for changes you could have steered in two minutes.

Frequently asked questions

Is the coding agent the same as the cloud agent? Yes. GitHub renamed Copilot coding agent to Copilot cloud agent. Same feature.

Can I use the cloud agent on Copilot Free? No. It is available on all paid plans and on the free Copilot Student plan, but not on Copilot Free. See the plans comparison.

How do I assign work to the cloud agent? From the agents panel and other entry points on GitHub.com, from a GitHub issue, from VS Code, or by mentioning @copilot in a pull request comment. Tasks can also be triggered on a schedule or by an event.

Can the cloud agent work on several repositories at once? No. One repository per task.

What happens if it cannot finish? Sessions are capped at 59 minutes. A task that exceeds that does not complete — which is usually a signal the task was too large.

Does agent mode need the internet? Yes. Every Copilot surface requires connectivity to GitHub’s services.

Can I stop an agent mid-run? In agent mode, yes — you can interrupt at any point, and editors supporting checkpoints let you roll back to an earlier state.

Next steps

For the in-editor agent in depth, see GitHub Copilot Agent Mode Explained.

For the prompting discipline that makes both agents produce reviewable work, see Best Practices for Beginners.

The cloud agent, custom agents, subagents and MCP are covered properly in Cluster 7 of the Academy roadmap.