GitHub Copilot Agents Part 2: Harnesses, the Agent Host, Cloud Sandboxes and AI Credits Explained

TL;DR

The four agent types I described in January are no longer the right map for VS Code. Choose a harness, where the session runs and a model, then set the role and permissions.

The Copilot harness is now the default. It shares a runtime with other Copilot products and runs through the Agent Host, so a session can outlive its editor window, but not a stopped host.

Cloud sandboxes let work continue without your laptop. Under GitHub AI Credit billing, sub-agents consume tokens at their own models’ rates, so context isolation is still useful, but it isn’t free.

In a hurry? Jump to the updated decision guide, then come back for the architecture and the money bit.

Ten months is a long time in agent land

When Part 1 went out on 10 January, I split GitHub Copilot agents into Local, Background, Cloud and Sub-agents. It was a useful way to explain the workflows, but it mixed together where an agent ran, how you interacted with it and how it delegated.

Since then, VS Code has moved to weekly releases, GitHub has rebuilt Copilot billing, and the old boxes have stopped lining up with the controls in front of us.

The better mental model is one Copilot engine with many cockpits, alongside other providers’ harnesses. This post is a November 2026 snapshot, checked against the primary sources on 3 November, covering VS Code 1.144 and GitHub’s 28 October cloud rollout.

What happened to the four types

The biggest change isn’t a rename. The old categories have been pulled apart into choices you can make separately.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: From four agent types to three separate choices
    accDescr: January's Local, Background, Cloud and Sub-agent categories mixed several concepts. November separates the harness, execution environment and model, with Copilot as the default harness.
    JAN["January: four types
Local, Background,
Cloud and Sub-agents"]
    NOV["November: three choices
Harness
Environment
Model"]
    DEFAULT["Copilot is the default
Local remains for migration"]
    JAN -->|"separate the concepts"| NOV --> DEFAULT
    classDef historical fill:#f6f8fa,stroke:#8c959f,color:#000,stroke-dasharray:5 5
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef data fill:#fff4c2,stroke:#b7950b,color:#000
    class JAN historical
    class NOV focus
    class DEFAULT data

The work we used to divide between Local and Background is converging on the Copilot harness. It became the default for new sessions in VS Code 1.143. Local remains available for editor workflows and integrations that haven’t migrated yet.

The coding agent became Copilot cloud agent, and research, plans and branch-only work joined the original pull request workflow. The newer cloud experience defaults to a managed sandbox where that environment choice is offered.

Sub-agents haven’t disappeared. They’re still isolated workers, but the delegation tool depends on the harness, and their model calls are metered under AI Credit billing.

Two things also need correcting rather than presenting as new features. You could already steer the coding agent while it worked in October 2025. And VS Code’s Autopilot arrived in 1.111 in March 2026, not January. I’ve added notes to Part 1 rather than quietly rewriting its history.

The new mental model: harness, environment, model

Start a session by separating the agent loop from the machine running its tools and the model answering its requests.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: The choices that define an agent session
    accDescr: Choose a harness, an execution environment and a model. Then choose the role and permission settings supported by that harness. Not every combination is available.
    H["Harness
Copilot, Local,
Claude or Codex"]
    E["Environment
this computer or container
remote host or cloud"]
    M["Model access
Copilot, provider credentials
or supported local models"]
    R["Then: role and permissions
within that harness"]
    H --> E --> M --> R
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef output fill:#e6ffed,stroke:#2da44e,color:#000
    classDef data fill:#fff4c2,stroke:#b7950b,color:#000
    class H focus
    class E output
    class M,R data

These are separate choices, not a promise that every combination exists. Cloud is an execution target for the Copilot harness, not a fifth harness. Local only lives in the editor’s Chat view.

The naming is a trap worth calling out: Local is a harness name, not a synonym for running on your machine. Copilot, Claude and Codex can also run tools on your machine. None of that guarantees local model inference or that your code stays offline.

Changing the model doesn’t change the harness either. A Claude model inside a Copilot session still uses Copilot’s agent loop, tools and customisations. Selecting the Claude harness is a different decision.

Copilot: the default starting point

The Copilot harness uses the Copilot SDK and runs through the Agent Host. Use it for day-to-day coding, background work and sessions you want to open in both the editor and the Agents window.

In the Session Target control, choose Copilot, then the model and built-in agent. Ask researches without making changes, Agent implements and validates, and Plan researches an approach for review, also available through /plan. Custom agents appear in the same picker.

Local: the editor-bound migration option

Local uses VS Code’s earlier built-in harness in the extension host. Its session belongs to the editor window, so closing that window stops ongoing work. It isn’t available in the Agents window.

Keep it when an integration still depends on Local-specific tools or customisations, not because the word sounds more private. Before migrating, check tool availability, MCP configuration and hooks rather than assuming the files mean the same thing in both harnesses.

Claude and Codex: different harnesses, not just models

Claude integrates Anthropic’s Claude Agent SDK. Codex uses OpenAI’s integration, either through its extension or the experimental Agent Host route. They retain their own agent behaviour and provider-specific configuration.

Claude support is enabled by default where policy permits it. Codex requires opting into an integration; the Agent Host route has its own authentication requirements, including Pro+ for the Copilot-backed option.

There is an important enterprise caveat: the Claude and Codex harnesses are disabled when Copilot enterprise-managed settings apply, including managed permission or sandbox settings. Separate provider credentials don’t bypass that restriction.

The harness guide is the source to check when a target is missing from your picker.

One Copilot engine, many cockpits

This is the architectural change that makes the rest less confusing. VS Code’s Copilot harness, the CLI, the Copilot app, cloud sessions and Copilot code review share the Copilot runtime. Claude and Codex remain separate harnesses.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: Copilot interfaces share a runtime that applications can also use
    accDescr: VS Code, Copilot CLI, the Copilot app, cloud sessions and code review share the Copilot harness. The SDK exposes that engine to custom applications.
    CLIENTS["Copilot clients
VS Code, CLI and app
cloud sessions
and code review"]
    RUNTIME["Shared Copilot harness
agent loop, tools
and customisations"]
    SDK["Copilot SDK
embed in your own app"]
    CLIENTS -->|"share"| RUNTIME
    RUNTIME -->|"exposed through"| SDK
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef data fill:#fff4c2,stroke:#b7950b,color:#000
    classDef output fill:#e6ffed,stroke:#2da44e,color:#000
    class CLIENTS output
    class RUNTIME focus
    class SDK data

The Copilot SDK became generally available on 2 June, with TypeScript, Python, Go, .NET, Rust and Java SDKs. By default, an SDK drives the Copilot CLI in server mode over JSON-RPC. An experimental in-process transport is also available, so a separate CLI process is the default architecture, not the only one.

Standard SDK use needs a Copilot subscription, including the Free tier for personal use. Bring your own key is a separate route that can work without a Copilot subscription, with usage billed by that provider.

Sharing a runtime makes instructions, skills, custom agents, hooks and plugins more portable. It doesn’t make every surface identical. Tools, model access, permissions, discovery locations and supported customisations still differ. The migration guide is more useful than copying configuration until the errors stop.

Prompt files are a particular migration concern: workflows that depend on the Local harness’s prompt files should move reusable procedures into skills for the Copilot harness. Copilot Memory is another shared capability across supported surfaces, but it isn’t a promise that all personal settings or session history automatically synchronise.

One SDK default deserves attention before embedding it in a tool: it exposes the CLI’s first-party tools by default, similar to --allow-all. Execution is still governed by the SDK’s permission handler. Configure that handler and the available tools deliberately rather than treating an embedded agent as a harmless text-completion API.

The Agent Host: sessions that outlive the window

The Agent Host is a dedicated process that owns sessions, their terminals and their changes. The editor window is a client of that process, not the place the whole agent has to live.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: Clients connect to an Agent Host running beside the code
    accDescr: The editor, Agents window and browser connect to an Agent Host. The host owns session state and runs harnesses beside the workspace.
    CLIENT["Editor, Agents window
or browser"]
    HOST["Agent Host
session state
terminals and changes"]
    HARN["Harness adapters
Copilot, Claude and Codex"]
    CODE["Code and tools
this computer, a container
or a remote host"]
    CLIENT -->|"Agent Host Protocol"| HOST
    HOST --> HARN --> CODE
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef output fill:#e6ffed,stroke:#2da44e,color:#000
    class HOST,HARN focus
    class CLIENT,CODE output

Clients communicate through the open Agent Host Protocol. Version 1.0 arrived with VS Code 1.144. The host owns the authoritative state, so several clients can observe and steer the same session instead of each creating a copy.

The distinction that matters in practice is session lifetime.

Close a project or editor window, and a Copilot harness session can keep working while its Agent Host remains running. Quit the VS Code application that manages that local host, and the work stops. Put the laptop to sleep, and local work doesn’t magically continue elsewhere.

A remote session can continue if its remote machine and serving process stay running. A cloud sandbox doesn’t depend on your laptop, although the service still manages its availability and lifecycle. Being able to reopen a conversation isn’t proof that its agent kept working while its host was stopped.

For an overnight job, choose a host that will actually stay available. Window independence is not machine independence.

Connected windows can lend tools to a session, including extension and browser capabilities. Those tools need their lender to stay connected, even if the host itself can keep going.

For a standalone host, the documented command is code agent host; --tunnel exposes it through a dev tunnel. GitHub Environments, currently in preview, lets you register an existing machine and access supported sessions from other Copilot clients. Registration doesn’t provision compute or move your workspace. Your machine still has to stay on.

Handoffs have changed

Part 1 described a smooth Local to Background to Cloud escalation path. That isn’t a general pipeline inside the current VS Code experience.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: A VS Code Local session can hand off, but not through an unlimited chain
    accDescr: A Local session can carry its history to Copilot, Claude or experimental Codex. Those sessions cannot hand off again to another harness or the cloud.
    LOCAL["VS Code Local session"]
    DEST["Copilot, Claude or
experimental Codex"]
    STOP["No further handoff
start a cloud session
when you need the cloud"]
    LOCAL -->|"history and context"| DEST --> STOP
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef data fill:#fff4c2,stroke:#b7950b,color:#000
    classDef warning fill:#ffd6d6,stroke:#c0392b,color:#000
    class LOCAL data
    class DEST focus
    class STOP warning

A Local session can hand off to Copilot, Claude or the experimental Codex integration, carrying its conversation history and context. Those destination sessions can’t then hand off to another harness or to the cloud. Starting a new cloud session is a separate operation; it doesn’t automatically copy your local uncommitted changes.

The terminal CLI still supports /delegate, or a prompt beginning with &. That delegates a task to Copilot cloud agent, creating a branch and draft PR. It isn’t the same operation as selecting another harness in VS Code.

For an interactive CLI session whose tools run in a cloud sandbox, start it with:

copilot --cloud

That starts a new cloud session rather than moving the current local conversation. Once a cloud sandbox session exists, supported clients can reconnect to the same session. Continuing a session, handing off a task and starting another session are three different things.

The cloud side: Copilot cloud agent and cloud sandboxes

The cloud agent has grown beyond “assign an issue and wait for a PR”. You can ask for research, approve a plan before implementation, iterate on a branch and request a PR when you’re ready.

The newer connected experience also changes where that work runs. Check the selected environment before starting, because the default and available choices still depend on the client and workflow.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: Choose Actions when the repository needs Actions-specific capabilities
    accDescr: Use Actions for Actions setup steps, runner customisation or Windows. Otherwise, a managed Linux cloud sandbox is the default where offered.
    START["Need Actions-specific
setup, runners or Windows?"]
    ACTIONS["Actions"]
    CLOUD["Cloud sandbox"]
    START -->|"yes"| ACTIONS
    START -->|"no"| CLOUD
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef output fill:#e6ffed,stroke:#2da44e,color:#000
    classDef data fill:#fff4c2,stroke:#b7950b,color:#000
    class START focus
    class CLOUD output
    class ACTIONS data

Cloud sandboxes: the new default where offered

A cloud sandbox is a GitHub-hosted Linux environment with its own workspace. It can keep working without your machine, saves a snapshot when stopped and can resume across supported Copilot clients.

Unlike Actions-based agent sessions, sandboxes don’t have the one-hour total running-time limit. They can also work across repositories in one organisation, or across repositories owned by your personal account. Access and organisation policies still apply.

The connected cloud experience and sandboxes became generally available on paid Copilot plans on 28 October. Entry points include GitHub.com, Mobile, the CLI, the Copilot app, VS Code, Slack and Teams. Availability in a service doesn’t mean every client’s integration has the same maturity.

Actions: still needed for some repositories

Choose Actions when the repository needs copilot-setup-steps.yml, Actions-specific setup such as OIDC sign-in, larger or self-hosted runners, or a Windows environment. Those settings don’t automatically transfer into a cloud sandbox.

Actions-based agent sessions still have a 59-minute execution limit and are scoped to one repository. GitHub also documents a one-branch, one-pull-request-per-task limitation. A sandbox’s broader repository access isn’t a promise of unlimited PR creation within one task.

Remote environments: your compute, your lifecycle

A registered machine or VM is another option when you need an environment you control. Unlike a managed sandbox, you maintain the machine, dependencies and uptime.

Automations can initiate recurring work on schedules or repository events, subject to feature availability, eligible repositories and policy. A cloud automation doesn’t need your laptop; an automation running locally still needs its host.

Security checks are defaults, not an absolute guarantee

Part 1 called security validation non-negotiable. The current security documentation says repository administrators can disable individual validation tools.

By default, the cloud agent uses CodeQL, secret scanning and checks of new dependencies against the GitHub Advisory Database. The validation doesn’t require a GitHub Advanced Security licence. Keep it enabled, inspect the results and review the code yourself. Automated scanning isn’t proof that a change is safe.

Claude and Codex are also available as third-party coding agents on GitHub, currently in public preview and subject to account policies. They receive security validation and consume AI credits plus Actions minutes. Don’t confuse those hosted agents with simply selecting one of their models inside Copilot.

Sub-agents: the same context benefit, a different bill

The useful part of Part 1 still stands. A worker can investigate a bounded question in its own context and return a focused answer, without filling the main thread with every file read and intermediate result.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: Isolated workers return focused results to the main agent
    accDescr: The main agent delegates independent research and review tasks to workers with their own context. Focused results return to the main agent for implementation. Each worker's model calls contribute to usage.
    MAIN["Main agent
assigns scoped tasks"]
    RESEARCH["Researcher
own context"]
    REVIEW["Reviewer
own context"]
    RESULTS["Focused results
not every intermediate step"]
    NEXT["Main agent
implements and validates"]
    MAIN --> RESEARCH & REVIEW
    RESEARCH & REVIEW --> RESULTS --> NEXT
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef data fill:#fff4c2,stroke:#b7950b,color:#000
    classDef output fill:#e6ffed,stroke:#2da44e,color:#000
    class MAIN,NEXT focus
    class RESEARCH,REVIEW data
    class RESULTS output

The delegation mechanism now depends on the harness. Copilot uses its native task tool; Local uses runSubagent, exposed through the agent tool set. Claude and Codex manage their own provider-native sub-agents.

That is more than a spelling change. When migrating a coordinator, review its tool list, prompts and expected arguments. Don’t mechanically replace runSubagent with task and assume the contracts match.

Give a research worker a smaller job and model

For a Local harness example, create .github/agents/repo-researcher.agent.md with a read-only tool list and a model suited to lightweight research:

---
name: Repo Researcher
description: >-
  Find files and patterns.
  Never edit.
user-invocable: false
tools: ['read', 'search']
model: >-
  Claude Haiku 4.5 (copilot)
---
Research the assigned topic.
Do not change any files.
Return the relevant paths,
the existing pattern and
any unanswered questions.
Use fewer than 200 words.

This is a Local harness example, not a universal configuration for all four harnesses. Choose an available model from your picker and compare its current price with the parent model. user-invocable: false hides the worker from the picker without preventing agent invocation.

Local’s model selection order is an explicit tool-call preference, then the custom agent’s model, then Auto if chat.subagents.defaultToAuto is enabled and applicable, then the parent model. Explicit and agent-configured selections can’t exceed the parent’s cost tier. Auto routing has separate rules, so that isn’t a universal guarantee that a worker can never use a pricier model.

Local invocations are stateless and don’t inherit the conversation history. Supply the goal, necessary context, allowed actions and expected result. Nested Local sub-agents are off by default; enabling chat.subagents.allowInvocationsFromSubagents permits nesting up to five levels.

Make the cost visible

Enable chat.subagents.showCreditUsage to show credit usage in the worker’s response pill and hover details. It is hidden by default. In the Agents window, you can inspect a worker’s model, elapsed time and active tool call.

Delegation adds model usage and coordination. Use it when separate context, independent work or a cheaper model is worth that overhead. A quick lookup doesn’t need a miniature organisation of agents.

Guardrails: permissions, Autopilot and sandboxing

There are three separate controls here, and confusing them is an easy way to grant more autonomy than you meant to.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: Permissions, Autopilot and terminal sandboxing are separate controls
    accDescr: Permission levels govern approvals. The workflow mode controls how autonomously the agent continues. Terminal sandboxing is a separate layer and does not cover every tool.
    PERM["Approvals
Manual, Assisted
or Allow all"]
    AUTO["Workflow
Agent or Autopilot"]
    SBX["Terminal sandbox
file and network limits"]
    LIMIT["Other tools need
their own controls"]
    PERM -->|"combine with"| AUTO
    AUTO -->|"separate layer"| SBX
    SBX --- LIMIT
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef data fill:#fff4c2,stroke:#b7950b,color:#000
    classDef warning fill:#ffd6d6,stroke:#c0392b,color:#000
    class PERM focus
    class AUTO,SBX data
    class LIMIT warning

In Copilot harness sessions, Manual permissions follows your configured approval rules. Assisted uses an LLM judge to assess tool calls and asks you about those it doesn’t approve. Allow all runs tools without confirmation.

Assisted became generally available in VS Code 1.144 and requires Folder isolation. Worktree sessions always use Allow all. A worktree separates Git changes; it doesn’t isolate the agent from the rest of your machine.

Autopilot is an agent mode in the Copilot harness, not another permission level. It auto-approves tools, retries errors and answers questions that would otherwise block progress. In the Local harness, Autopilot is still selected as a permission level. That harness-specific difference matters when following older instructions.

Sandboxing is separate again. An enabled terminal sandbox restricts file system and network access even under Allow all or Autopilot. It doesn’t cover every tool, so it isn’t a substitute for tool and URL controls. Local terminal sandboxing is in preview on macOS, Linux and WSL2, and experimental on Windows.

Neither Assisted nor Autopilot guarantees good judgement. Both can make mistakes, and their model usage belongs in your cost planning too.

The money bit: from premium requests to AI credits

GitHub moved Copilot to usage-based billing on 1 June 2026. One GitHub AI Credit is $0.01 USD, and metered model usage is priced from input, output and cached tokens at the selected model’s rates.

The important unit is no longer just the prompt you typed. An agent task can make many model calls, with more calls in its workers.

%%{init: {"htmlLabels": false, "flowchart": {"htmlLabels": false, "nodeSpacing": 15, "rankSpacing": 30, "padding": 10}}}%%
flowchart TB
    accTitle: Every model call in an agent task contributes to usage
    accDescr: Main-agent and worker model calls consume input, output and cached tokens at each model's rates. These costs draw from the AI Credit allowance and permitted additional usage.
    PROMPT["One user task"]
    CALLS["Main and worker
model calls"]
    TOKENS["Input, output
and cached tokens
at each model's rates"]
    AI["GitHub AI Credits
included allowance,
then permitted extra usage"]
    PROMPT --> CALLS --> TOKENS --> AI
    classDef focus fill:#cce5ff,stroke:#1f6feb,color:#000
    classDef warning fill:#ffd6d6,stroke:#c0392b,color:#000
    class PROMPT,CALLS focus
    class TOKENS,AI warning

Under legacy premium-request billing, user prompts or cloud agent sessions were the relevant units, with model multipliers. Tool calls made within an agent’s work weren’t each a new user request. That’s the context behind Part 1’s advice about effectively free sub-agents.

Under AI Credit billing, worker model calls consume usage at their own models’ rates. A shell command isn’t itself a model call, but its output can become input to the next one. Repeated context and long conversations still count, although cached input may have a different price.

Check the billing model before comparing numbers

Some existing annual Pro and Pro+ subscribers chose to remain on legacy premium-request billing until their annual plan ends. Those accounts are an exception to the general migration, not evidence that worker model calls are free on usage-based plans.

Inline code completions and next edit suggestions aren’t billed in AI credits. Nor are responses actually run by the experimental on-device model. A local harness calling a hosted model is not that on-device exception.

Copilot Fusion also isn’t free routing. It bills the models it uses at their standard rates, with the current 30% paid-plan discount running through 30 November 2026.

Treat model usage and cloud execution as separate budgets

Cloud sandboxes have compute, allocated-memory and stopped-snapshot-storage meters. Compute and memory can draw from the shared included compute entitlement also used by eligible Actions runners. That isn’t your AI Credit allowance.

GitHub announced sandbox billing would begin in November 2026. Check the sandbox billing documentation for the applicable rates and controls. Stopping a sandbox stops compute and memory metering, but retained snapshots still consume storage.

An AI Credit budget alone doesn’t cap sandbox spending. Configure the relevant product or SKU budget too, and enable its stop-usage option when you need a hard limit rather than an alert.

What I’d do about it

Give workers cheaper models when the task allows it, keep their briefs bounded and avoid sending the same large context to several agents without a reason. Keep the main thread focused rather than paying a frontier model to repeatedly reread everything.

For teams, included usage is pooled: Business contributes 1,900 AI credits per seat per month and Enterprise contributes 3,900. User-level budgets cap total consumption, including usage drawn from the pool; spending limits at other levels can control additional charges. Those are different controls, so check which one you’re setting.

The point isn’t to avoid delegation. It’s to stop treating delegation, Fusion and Autopilot as invisible work outside the meter.

Part 1’s decision guide, rewritten

Pair on code or plan a change

Start with the Copilot harness in the Chat view. Use Ask to understand the code, Plan to review an approach and Agent to implement it. Choose a different harness for its behaviour or integrations, not simply because you want one of its provider’s models.

Keep working after closing an editor window

Use an Agent Host-backed Copilot session and keep VS Code and the host running. If the requirement is “keep working with my laptop shut”, choose a remote machine that stays on or a cloud sandbox instead.

Fix an issue overnight and review it in the morning

Use a cloud session with clear acceptance criteria. Ask for a plan first when the approach needs review, or ask explicitly for a pull request. Select Actions if the repository depends on Actions-specific setup or runners.

Work on several features without mixing the changes

Use separate sessions and worktrees in the Agents window. This isolates Git changes, not security permissions. Compare the extra model usage with the value of independent work.

Research without filling the main context

Use a bounded sub-agent on an appropriate cheaper model. Give it enough context to work independently and ask for a concise result. For a small lookup, stay in the main session.

Reuse a provider workflow, schedule a job or embed an agent

Choose Claude or Codex when you need their native harness and policy permits it. Use an automation for a recurring job, selecting a host that will be available when it runs. Use the Copilot SDK to put the Copilot runtime inside your own application.

Keep Local only for a workflow that still needs it while you migrate.

How we got here

The release dates make the pace easier to appreciate:

• 25 February: the Copilot CLI became generally available.
• 9 March: VS Code 1.111 began weekly Stable releases and introduced Autopilot.
• 1 April: the renamed cloud agent added branch-only work and plans.
• 1 and 2 June: AI Credit billing went live, followed by Copilot SDK general availability.
• 17 June: the Copilot app became generally available.
• 15 July: VS Code 1.129 began rolling out the Agent Host.
• October: 1.143 made the Copilot harness the default; 28 October brought the connected cloud experience and VS Code 1.144 with AHP 1.0.

Those changes explain why a January comparison table now needs more than a few renamed columns.

Honest limits

Cloud sandboxes are generally available, but VS Code’s cloud-session integration still has experimental settings and account requirements. The Dev Container and direct Codex integrations also have their own maturity and setup constraints.

The Copilot harness doesn’t yet expose every Local tool or customisation. Enterprise policy can restrict harnesses, models, permissions and environments, or move a Local session to Copilot so the runtime can enforce the policy.

The docs describe several overlapping generations of workflows. When checking sub-agents and permissions, use the documentation for your actual harness. When checking cloud behaviour, distinguish managed sandboxes from Actions-based sessions.

This will date again. Treat the dates, preview labels and discounts as a snapshot, not permanent promises.

My take

The headline isn’t any single feature. It’s convergence. In January I was explaining four agents with four rulebooks. Today the useful questions are which harness should run the loop, where its tools should run and which model should do the thinking.

For Copilot, one engine with many cockpits is a much better mental model. Just don’t mistake a common engine for identical capabilities everywhere, or a persistent conversation for compute that never stops.

The bit I’d flag to every team lead is cost. Sub-agents remain a useful context-management tool, but every worker needs to earn its model usage. Give it a bounded job, choose its model deliberately and turn the credit meter on.

Key takeaways

• Choose the harness, execution environment and model separately. Local is a harness name, not a privacy or offline guarantee.
• Agent Host sessions can outlive an editor window, but they still need a running host. Use remote or cloud compute for work that must outlive your laptop.
• Cloud sandboxes bring resumable sessions and broader repository scope; Actions remains necessary for some setup and runner requirements.
• Delegation tools and permission semantics depend on the harness. Review integrations rather than relying on old tool names.
• Under AI Credit billing, the main agent and its workers all contribute model usage. Cloud execution has separate meters and budget controls.

References

• Choose an agent harness, VS Code
• Agent Host architecture, VS Code
• Use subagents, VS Code
• Manage approvals and permissions, VS Code
• VS Code 1.144 release notes
• GitHub Copilot SDK: architecture, authentication and tools
• Copilot on GitHub.com and GitHub Mobile: environments and limitations
• Cloud sandboxes: defaults, setup compatibility and lifecycle
• Billing for cloud and local sandboxes
• AI Credit billing for individuals
• AI Credit billing for organisations and enterprises
• Legacy billing exceptions for existing annual plans

Related posts

• Part 1: The Four Types of GitHub Copilot Agents, preserved with update notes as a historical snapshot.
• AGENTS.md vs Copilot Instructions vs Cursor Rules vs CLAUDE.md, for the context files and customisations around the agent.

Image Credits

• Cover image generated by Copilot