When a coding tool offers local, background and cloud agents, choosing a model is only part of the decision. You are also choosing where the work runs, how easily you can steer it, how isolated it is from your current workspace and how visible the work is to other people. VS Code now exposes all three modes in one agent workflow, which makes the trade-offs unusually explicit.
The three modes are not interchangeable
VS Code's own comparison separates the modes on four practical criteria: where the agent runs, whether the session is interactive or unattended, whether its changes are isolated and whether the work has team visibility.
Local: use it when you expect to steer
A local agent runs on your machine against the current workspace and is interactive. VS Code describes local work as the choice when you need to steer. That makes it a natural fit for exploratory work: you can watch what the agent is doing, answer questions and change direction while the task is still taking shape.
The trade-off is isolation. In VS Code's comparison, the local mode works directly in the workspace rather than in an isolated worktree or remote environment. If the task is poorly bounded, the cost of a bad assumption can therefore land directly in the working copy you are using.
Background: use it for unattended work that should stay on your machine
VS Code describes a background agent as an asynchronous CLI task running on your machine. It is unattended, but its changes are isolated in a worktree. That combination is useful when the task is clear enough to delegate and you want to keep working without giving the agent your active workspace.
The important distinction from a local session is not that the model is necessarily different. It is the execution boundary. You give up continuous interaction in exchange for an isolated branch of work that can progress separately.
Cloud: use it when remote isolation and team-visible work matter
A cloud agent runs on remote infrastructure and works asynchronously. In VS Code's comparison it is isolated remotely and can surface its work through pull requests and issues, giving it team visibility that the local and background modes do not have.
VS Code gives a well-defined refactor as an example of a task to send to a cloud agent. Its earlier GitHub Copilot coding-agent integration shows the same pattern in more detail: the agent works in a temporary isolated development environment, produces a pull request, can report its progress and can respond to review feedback.
That makes cloud delegation attractive when the work is already clear enough to hand off and the review boundary is the pull request rather than an ongoing conversation. It does not make the task safe merely because it is remote. You still need to decide what the agent is allowed to change and what evidence you require before accepting the result.
Choose by steering, isolation and visibility
A simple decision sequence is more useful than choosing a mode by habit.
- Will you probably need to redirect the work while it is happening? Prefer a local interactive session.
- Is the task clear enough to run unattended, but should execution stay on your machine? A background session gives you asynchronous work with worktree isolation.
- Does the task suit remote execution and benefit from pull-request or issue visibility? A cloud session gives you remote isolation and a team-visible review surface.
These are not hard categories. VS Code itself describes agent use as ranging from hands-on to fire-and-forget depending on the task. The point is to make the execution choice deliberately rather than defaulting every request into whichever chat window is already open.
Well-defined work becomes more important as interaction decreases
The less you expect to interact with the agent during the run, the more useful it is to settle the task boundary beforehand. A local exploratory session can absorb clarification while you are watching it. An unattended session has to make more of those decisions without you.
Before sending work into a background or cloud session, make the acceptance boundary visible: what behaviour should change, what should remain untouched, which check demonstrates success and which files or systems are outside the task. That does not dictate the implementation. It gives the agent something concrete to finish against.
This is the same control problem discussed in When an Agent Decides to Act Without You Asking: autonomy changes when decisions are made, not whether those decisions matter.
Isolation changes what a failed attempt costs
VS Code's three modes also make a useful distinction between direct-workspace execution, worktree isolation and remote isolation. If an exploratory attempt goes wrong in an isolated environment, the failed attempt is easier to inspect without disturbing the version you are actively using.
That is why background and cloud modes can be useful even when you are not trying to maximise concurrency. Isolation gives you a cleaner boundary between the agent's attempt and the version you currently trust. The principle is similar to running alternative attempts in separate worktrees before deciding which one deserves to be merged.
For that workflow in a more explicit form, see Worktree Isolation and Best-of-N.
Multiple agents create a tracking problem
Once several sessions can run at once, the practical failure mode is no longer just a bad edit. It is losing track of which agent is doing what, which run is still active and which result is waiting for review.
VS Code's Agent Sessions view is designed as one place to see local, background and cloud sessions, check their state and move between them. Its unified agent experience also allows a running session to be opened and, where supported, course-corrected. The transferable lesson is to keep concurrent agent work visible as a set of named, reviewable sessions rather than treating it as invisible background activity.
The mode should follow the task
Use local work when the problem is still being discovered and steering is valuable. Move clear, bounded work to a background agent when you want it isolated but still running on your machine. Use a cloud agent when remote execution and a team-visible pull-request or issue workflow are useful.
None of those modes removes the need to review what changed. They change the place where the agent works and the point at which you interact with it. Choosing that boundary before the run starts is part of directing the work, not an implementation detail.