There are two different things people mean by “running agents in parallel” with Claude Code, and they solve different problems. One is in-session subagents — the main thread delegating focused work to helpers that share your working tree. The other is running several Claude Code instances at once, each in its own git worktree on its own branch, doing genuinely separate work.
They’re easy to conflate because both involve more than one agent. But the boundary is sharp: subagents share a working directory and are coordinated by a single main thread; parallel instances are isolated checkouts that you coordinate yourself. Pick the wrong one and you either fight merge conflicts you didn’t need or serialize work that could have run side by side.
This compares the two, lays out the trade-offs, and gives a worktree setup that works on Windows and WSL. If subagents are new to you, the subagents guide covers the basics first.
The two models
Subagents vs parallel instances
| In-session subagents | |
| Process | One Claude Code session |
| Working tree | Shared |
| Branch | Same branch |
| Coordination | Main thread handles it |
| Context | Isolated per subagent |
| Best for | Coordinated work on one feature |
Subagents are about context isolation within a single line of work. The main agent stays in charge, delegates reading or reviewing or testing, and stitches the results together. Everything happens against one working directory and one branch.
Parallel instances are about throughput across independent lines of work. Each runs in its own worktree — a separate checkout of the same repo on its own branch — so three agents can build three unrelated features simultaneously without touching each other’s files.
When subagents fit
Reach for subagents when the work shares a working tree and benefits from a single coordinator. That’s most day-to-day development:
- Exploring a feature, then planning and editing it in one flow.
- Writing code on the main thread and delegating review to a reviewer agent.
- Generating tests for the code you just wrote.
The main thread can fan out to several subagents at once — say, three explorers mapping different parts of the codebase — and because that work is read-only, sharing the working tree is fine. The wins are simplicity (no branch management) and clean context (each subagent’s noise stays out of the main thread).
For which subagents are worth building for this kind of coordinated work, see the best subagents list.
When worktrees fit
Use parallel instances across worktrees when you have several tasks that are genuinely independent — different files, no need to coordinate mid-task. Building an auth feature, a reporting page, and a CLI flag at the same time, for example. Each gets its own worktree, its own branch, its own Claude Code session, and they run without interfering.
The cost is coordination. You own the integration: each branch gets merged back yourself, and overlapping changes can conflict. Token spend also scales with the number of instances, since each session is independent.
Trade-offs at a glance
| Concern | Subagents |
|---|---|
| Setup complexity | Low |
| Merge conflicts | None (one branch) |
| True parallel edits | No |
| Cost control | Easier (one session) |
Setting up git worktrees on Windows and WSL
A worktree is a second working directory attached to the same repository, checked out to a different branch. From inside your repo:
# create a worktree for a new branch in a sibling folder
git worktree add ../myproject-auth -b feature/auth
git worktree add ../myproject-reports -b feature/reportsEach command creates a folder with its own checkout on its own branch. Open a separate terminal in each and start Claude Code there:
cd ../myproject-auth
claudeNow each folder has an independent Claude Code session working on an isolated branch. List and clean up worktrees when you’re done:
git worktree list
git worktree remove ../myproject-authOn native Windows, the same commands work in PowerShell — just use Windows-style paths:
git worktree add ..\myproject-auth -b feature/authThat said, running the Claude Code instances inside WSL is usually smoother, because the shell tooling and path handling are more predictable than mixing PowerShell quirks across several sessions. Keep the repo and worktrees on the Linux filesystem rather than reaching across to /mnt/c for better performance. If you haven’t set that up, see the WSL install guide.
For running Claude Code across servers and managing this kind of multi-session setup, the setup for sysadmins covers the operational side.
A worked example: three features at once
Say you’ve got three independent tickets — an auth refactor, a reporting page, and a new CLI flag — and you want them moving in parallel. The worktree setup looks like this:
git worktree add ../app-auth -b feature/auth
git worktree add ../app-reports -b feature/reports
git worktree add ../app-cli -b feature/cliOpen three terminals, start claude in each folder, and brief each session on its ticket. Inside each session, the agent can still use subagents — a context-gatherer to map the relevant code, a reviewer before it wraps up — so you get parallelism across tickets and clean context within each. When a feature is done, commit on its branch, then integrate:
cd ../myproject
git merge feature/cli
git worktree remove ../app-cliMerge the small, low-conflict branches first to keep integration simple. The two things to watch: branches that touch the same files will conflict, and three live sessions cost roughly three times the tokens of one. That’s the price of throughput.
Managing cost across parallel instances
Subagents keep cost contained because everything runs under one session and you can route exploration to a cheap model. Parallel instances don’t have that built-in ceiling — each is a full session spending independently. A few ways to keep it sane:
Cost control with parallel instances
| Tactic | Effect |
|---|---|
| Limit how many instances run at once | Caps concurrent token burn |
| Use subagents inside each instance | Routes that instance's exploration to a cheap model |
| Reserve worktrees for genuinely independent work | Avoids wasted re-coordination |
| Merge and tear down finished worktrees promptly | Stops idle sessions lingering |
The honest framing: worktrees buy wall-clock speed at the cost of money and coordination overhead. If a job isn’t actually parallelizable, you’re paying both without the benefit.
Decision guidance
A simple way to choose:
- One feature, want clean context and coordination? Subagents. Let the main thread delegate exploration, review, and tests, and keep everything on one branch.
- Several independent features, want them built at once? Worktrees. Spin up an instance per branch and accept that you’ll integrate the results.
- Read-heavy parallel work? Subagents handle this well, even concurrently, because it’s read-only.
- Concurrent edits to different parts of the codebase? Worktrees, so the agents never share a working tree.
The two aren’t mutually exclusive. A common setup is parallel instances across worktrees, each of which uses subagents internally for review and exploration. That gives you throughput across features and clean context within each one.
Wrapping up
Subagents and parallel instances answer different questions. Subagents isolate context within a single coordinated line of work on one branch — simple, no merge management, ideal for review and exploration. Worktrees give you true parallelism across independent tasks, at the cost of coordinating branches and merges yourself.
Default to subagents for everyday work. Bring in worktrees when you have several genuinely independent features worth building at the same time — and on Windows, run them in WSL for the smoothest experience.
