The Copilot Cloud Agent and CLI

1. Two Kinds of Agent: Local Agent Mode vs. the Cloud Agent

Chapter 1 introduced Agent mode: you give Copilot an instruction inside your IDE, it plans and edits files locally, and you watch the changes land in your editor before you accept them. That loop is synchronous — you wait, Copilot works, you review.

GitHub's cloud agent is a different mechanism for a different kind of task. Instead of editing your local working copy, you hand it a task description and it starts an independent run in a secure GitHub Actions environment on GitHub.com. You don't watch it edit files in your IDE; it works on its own, and when it finishes it opens a branch and a pull request for you to review.

This split — local-and-synchronous versus cloud-and-asynchronous — is the durable idea to hold onto. It doesn't depend on what either mechanism happens to be called. As it happens, the cloud agent's own name has changed since some source material was written — more on that next.

2. Naming History: 'Coding Agent' Becomes 'Copilot Cloud Agent'

Older material — including earlier chapters of some Copilot books — calls this feature the "Coding Agent." Current GitHub documentation instead titles it "Copilot cloud agent." These are the same feature under two names, not two different products.

Going forward in this course, and in your own notes, use "Copilot cloud agent." If you land on a page, blog post, or older tutorial that still says "Coding Agent," read it as describing the same asynchronous, GitHub-hosted mechanism you just met in the previous section — just under its earlier name.

3. Who Can Use the Cloud Agent, and How It's Billed

Older source material states that the Coding Agent "is only available to paid Copilot plans (Pro+ and Enterprise), and administrators may need to enable the policy at the organization or enterprise level," and that it "uses one premium request per session, regardless of how many edits or files are involved." Both claims are now superseded — treat them as history, not as something to plan around today.

Current eligibility is more granular. Recall the Copilot plan your own account is actually on, as you recorded it in Chapter 2 Activity 3 — not the provisional team recommendation you justified there, since only your account's real plan determines what you can actually run. Here's how the cloud agent maps onto the current lineup:

• Pro, Pro+, and Max — enabled by default. No admin action needed.
• Business and Enterprise — disabled by default. An administrator must turn on an organization-level policy before anyone on the plan can use it; enterprises have several policy states to choose from.
• Free — not available.
• Copilot Student — included. This is worth calling out explicitly: Student is a free, verified-student plan, but it gets the same "included" cloud-agent access as Pro/Pro+/Max — it does not behave like Free.

If you're on Business or Enterprise, check your own org/enterprise admin settings before assuming the cloud agent is available to you; don't infer availability from the plan name alone.

Billing has changed to match. Instead of the old flat one-premium-request-per-session charge, a cloud agent run is billed as GitHub Actions minutes plus AI Credits based on the tokens the model actually processes. Those AI Credits use the same AI Credits mechanism you met in Chapter 2. This course's evidence does not establish whether cloud-agent usage draws on the same monthly allowance as your other Copilot activity or a separate pool, so this course asserts neither — check your own Copilot billing or usage settings if you need to know for certain. No documented source gives a typical dollar or credit figure for a session, so this course won't invent one — the mechanism, not a number, is what to take away. Administrators can still gate the feature by policy, and individual repository owners can opt it out even when their plan or org allows it.

4. The Copilot CLI: Bounded Tasks and the Volatility of 'Default Model' Claims

Older material states that the Copilot CLI "by default... uses Claude Sonnet 4.5," with a /model command available to switch to alternatives such as Claude Sonnet 4 or GPT-5. Treat that specific model name as superseded history — don't memorize it as today's default.

Some secondary, non-first-party research from August 2026 suggests the default may have moved to "Claude Opus 5." That value was never confirmed against GitHub's own documentation, so this course presents it only as an unconfirmed signal, not as today's fact. Neither name — the old one or the rumored new one — is safe to memorize.

What is confirmed and durable is the pattern itself: GitHub changes its default and available models on a cadence measured in months. That volatility, not any single model name, is the lesson.

The practical habit: before you rely on which model the CLI is using, check the CLI's own current-session output, or its model-listing/selection command, or the current GitHub docs page on default model availability — live, at the time you're working. Don't trust a memorized name, including any name in this course.

Activity 4 below walks you through this hands-on: you'll write down what you currently believe the default model is, then check what the CLI actually reports for your session and compare it to your expectation.

One more forward pointer before you close this chapter: the pull request your cloud agent (or fallback) produced in this chapter is exactly what Chapter 4 reviews next, using Copilot code review.

Activity 1: Map Agent Mode vs. the Copilot Cloud Agent

Goal: Lock in the conceptual split from this chapter's opening section before touching the cloud agent hands-on.

Steps:

1. Recall what Chapter 1 taught about Agent mode: what triggers it, where it runs, and how changes land in the IDE.
2. Search GitHub's own documentation for "cloud agent" — not "coding agent" — so you land on the current page. If you hit a page that still says "Coding Agent," recognize it as the older name for the same feature.
3. Build a short table comparing Agent mode and the Copilot cloud agent across four dimensions: trigger, execution location, synchronous vs. asynchronous, and typical output artifact.

Expected outputs:

• A short comparison table contrasting Agent mode and the cloud agent across trigger, execution location, synchronicity, and output artifact. A strong table clearly shows Agent mode as local and synchronous versus the cloud agent as GitHub-hosted and asynchronous, and uses "Copilot cloud agent" as the current name while noting that an older "Coding Agent" label exists for the same feature.

Hints:

• Agent mode runs inside your IDE and you wait on its result; the cloud agent runs independently in a GitHub-hosted environment and hands you a pull request when done.
• If a page still uses an older name, treat it as the older name for the same current feature, not a different product.

Checkpoint: Your table should show distinct, correct execution-location and synchronicity values for Agent mode versus the cloud agent, and your notes should name "Copilot cloud agent" as the current term while noting that an older name exists for the same feature. This mental model is what you'll apply when you delegate your first real task to the cloud agent later in this chapter.

Activity 2: Confirm Your Plan's Cloud-Agent Eligibility

Goal: Before attempting to use the cloud agent, confirm whether it's actually available to you.

Steps:

1. Recall the Copilot plan your own account is actually on, as you recorded it in Chapter 2 Activity 3.
2. Using the current eligibility matrix from this chapter, determine your plan's default-enabled status: enabled by default (Pro/Pro+/Max), admin-gated (Business/Enterprise), included (Copilot Student), or not available (Free).
3. If your plan is admin-gated, identify what an administrator would need to do — enable the organization-level policy — before you could use it.
4. Note in your own words how current billing (Actions minutes plus AI Credits based on tokens processed) differs from the old flat one-premium-request-per-session charge.

Expected outputs:

• A short, explicit determination: your actual plan, its eligibility status, and — if applicable — the exact admin action still needed.

Hints:

• Copilot Student is explicitly included, distinct from Free's "not included" status — don't assume all free-tier access behaves the same way.
• Free does not include the cloud agent at all, and Business and Enterprise require an administrator-enabled organization policy; if your plan is Free, or you're on Business/Enterprise without admin access, record that as a genuine access blocker rather than assuming availability — this recorded blocker is what the next activity's fallback path checks for.

Checkpoint: Your determination should match the current per-plan matrix for your actual plan, and should not restate the historical Pro+/Enterprise-only claim or the flat per-session billing claim as if they were still current — label them as historical if you mention them at all. If your plan is Free, or you're on Business or Enterprise without admin access and no policy is enabled, record that plainly as a genuine access blocker; this is what determines which path you take in the next activity.

Activity 3: Delegate a Scoped Task to the Copilot Cloud Agent, or Complete the Access-Blocked Fallback

Goal: Produce the pull request Chapter 4 reviews next — this is the chapter's central hands-on activity.

Steps:

1. Recall your eligibility determination from the previous activity.
2. Pick one small, well-bounded task on the reference project suited to autonomous delegation — a scoped bug fix, a small isolated feature, or a well-defined refactor with a clear, testable outcome. Make it distinct from any earlier interactive change you've already made.
3. If the cloud agent is enabled or admin-enabled for your plan (Pro/Pro+/Max by default, Copilot Student included, or Business/Enterprise with the org policy turned on): assign the task to the cloud agent through its current supported entry point, let it run to completion on its own without intervening mid-run, and record the branch and pull request it opens when it finishes.
4. If the previous activity recorded a genuine access blocker with no available admin path: produce the equivalent bounded change yourself using another available Copilot surface, such as local Agent mode. Open the resulting branch and pull request, and clearly label the PR description or your accompanying note as produced via that alternative surface — not by the cloud agent.
5. Either way, leave the pull request open and unmerged. Don't merge it in this chapter — Chapter 4's review exercise acts on it next.

Expected outputs:

• One open, unmerged pull request on the reference project, produced by the cloud agent on the preferred path or via another available surface and explicitly labeled as such on the fallback path.
• A brief note: which path you took, the task you gave, and the resulting branch/PR — including the access blocker you recorded, if you used the fallback.

Hints:

• Keep the task bounded and testable regardless of path; an open-ended task makes a poor delegation exercise and poor material for the next chapter's review.
• If you recorded a genuine access blocker, don't skip this activity — use the fallback path and label the PR clearly as not cloud-agent-produced.

Checkpoint: A pull request should exist, be open and unmerged, and be accurately attributed to how it was produced — cloud-agent commits on the preferred path, or an explicit alternative-surface label on the fallback path.

Activity 4: Use the Copilot CLI for a Bounded Task, Then Check the Model It Actually Used

Goal: Get hands-on CLI experience while confirming that the CLI's "default model" must be checked live, not memorized.

Steps:

1. Open the Copilot CLI and run one small, bounded task against the reference project.
2. Before checking anything, write down what you currently believe the CLI's default model is, and why.
3. Check the CLI's own current-session output — or its model-listing/selection command, or the current GitHub docs page on default model availability — to see what model actually ran your task.
4. Compare that live result to your written expectation, and to the two candidate values discussed in this chapter (the historical "Claude Sonnet 4.5" claim and the unconfirmed "Claude Opus 5" signal). Don't treat either name as confirmed.

Expected outputs:

• A completed bounded CLI task against the reference project.
• A short written comparison between your prior expectation and the model the live CLI session actually reports.

Hints:

• The point of this exercise isn't the specific model name you land on — it's practicing the habit of checking live rather than trusting a memorized default.

Checkpoint: Write your comparison as a demonstration of that volatility, not as a fact to remember afterward — it should check the live CLI session rather than asserting either candidate name as a confirmed current default.

Reference Project Continuity — Chapter 3

Starting state: The reference project already has a first small, interactive Copilot-assisted change from earlier chapters, plus a Copilot plan already selected and justified for its team scenario.

This chapter's contribution: In Activity 3, learners delegate one bounded, well-scoped task to the Copilot cloud agent — or, for a learner who recorded a genuine cloud-agent access blocker in Activity 2, complete the equivalent task via another available Copilot surface such as local Agent mode, explicitly labeled as not cloud-agent-produced. Either way, the result is one open, unmerged pull request on the reference project. In Activity 4, learners run a separate, small bounded task through the Copilot CLI, checking live what model actually served it rather than assuming a memorized default.

Ending state: The reference project has one open, unmerged pull request — cloud-agent-produced for learners with access, or accurately labeled as produced via an alternative surface for learners who used the fallback — plus a separate CLI-driven interaction. The pull request stays open and unmerged specifically because Chapter 4's code-review exercise acts on it next.

Sources

• The GitHub Copilot Handbook (book)
• https://docs.github.com/en/copilot/concepts/agents/cloud-agent/access-management
• https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent
• https://github.com/github/docs/blob/main/content/copilot/get-started/plans.md
• https://docs.github.com/en/copilot/get-started/plans
• https://docs.github.com/en/copilot/concepts/models/default-availability