Run agents in parallel

Choose between subagents, agent view, agent teams, projects and dynamic workflows when you want Claude Code working on several things at once.

Sooner or later one conversation is not enough. You want a test investigation running while you refactor, or a review happening on one branch while a migration grinds through another. Claude Code gives you five distinct ways to do that, and they differ mainly in two things: how much you stay in the loop, and where the work actually runs.

Every worker in every approach is a Claude session. If you want another tool to take part, expose it to Claude through an MCP server rather than looking for a different orchestration feature.

Note: Parallel work multiplies token use. Ten sessions spend your plan roughly ten times as fast as one. See Costs before you fan out.

The five approaches at a glance

Approach	Who drives it	Where it runs	Reach for it when
Subagents	Claude, inside your current conversation	Your machine, inside one session	A side job (searching, reading logs, running tests) would bury your main context in output you will never look at again
Agent view	You dispatch, then check in	Your machine, as background sessions	You have a handful of unrelated tasks to hand off and want one screen that tells you which ones need you. Research preview, opened with `claude agents`
Agent teams	A lead Claude that spawns and supervises teammates	Your machine	You want Claude to break a project apart, hand out the pieces and keep the workers talking. Experimental and off by default
Projects	One long-running conversation that spins up threads for you	The cloud, or your computer through Remote Control	The work spans days or weeks, should carry on when your laptop is shut, and you would rather describe it once than track each session yourself. Public beta on Pro and Max
Dynamic workflows	A script, not turn-by-turn judgement	Your machine	The job is bigger than a few subagents can coordinate, or you want results cross-checked: a repository-wide audit, a 500-file migration, research verified from several angles

Supporting tools

Three more features make parallel work safer without being a way to run agents in their own right.

Worktrees give each session its own git checkout so two sessions never write to the same files. Use them for sessions you start by hand. Sessions dispatched from agent view move into a worktree on their own before they edit anything, and subagents can be given one each.
Cross-session messaging lets Claude list and message your other sessions, whether they are on this machine, another machine or in the cloud. It is how independent sessions pass findings to each other.
/batch is a bundled skill that splits one large change across 5 to 30 subagents, each in its own worktree. It is a packaged pattern built from subagents and worktrees, not a separate coordination model. See Commands.

Things that look similar but are not

A few features let Claude work without you steering every step, but they solve different problems:

Background bash commands run a single shell command without blocking the chat. No agent is spawned. See Interactive mode.
Forked subagents are subagents that start with your whole conversation instead of a blank slate. You start one with /subtask, and Claude can spawn them itself when fork mode is on. If you want to copy the entire session into a new background session instead, use /fork. When agent view is turned off, /fork starts the forked subagent and /subtask does not exist. Details are in Subagents.
Routines run a session on a schedule in the cloud. That is about timing, not about splitting work.

Picking the right one

I ask myself three questions, in this order.

1. Who should coordinate?

Claude delegating and collecting results inside the chat I am already in: subagents.
Me handing off independent jobs and coming back later: agent view.
Claude planning the split, assigning tasks and supervising: agent teams.
A script holding the plan so nothing depends on Claude remembering it: dynamic workflows. The workflows page compares them with subagents and skills in more detail.

2. Do the workers need to talk?

Subagents report back to whoever spawned them. Named subagents can also message each other.
Agent view sessions report only to you, but Claude in any of them can use cross-session messaging to reach the others.
Agent team teammates message each other directly and, when they have the Task tools, share a task list.

3. Will they touch the same files?

If yes, isolate them. Subagents and hand-started sessions can each get a worktree. Agent team teammates are not isolated in worktrees, so you must divide the files up so each teammate owns a separate set.

Checking on running work

Each approach has its own status view, and the names are easy to mix up:

You want to see	Run
Every background session, its state and which ones are waiting on you	`claude agents` from your shell
Everything running in the background of this session, including finished subagents, with the option to attach or stop	`/tasks`
Running and completed dynamic workflow runs, their phase and how many agents have finished	`/workflows`
Where custom subagent files live	`/agents` (it prints a pointer to the folders; ask Claude or edit the files to change them)

Named background subagents also show up in the @ typeahead with their current status. Note that /agents inside a session and claude agents from the shell are different things despite the name.

If you prefer a GUI, the desktop app shows parallel sessions side by side.

A worked example

Here is how I split a typical Friday on a client repository:

In my main session I ask Claude to use a subagent to run the full test suite and report only the failures. The noisy output never reaches my context.
From a second terminal I run claude --bg "upgrade the Stripe SDK and fix any type errors". It appears in claude agents, moves itself into a worktree and opens a draft PR when done.
When the upgrade session finds that a webhook payload changed shape, Claude in that session messages my main session so I know before I touch the handler.

Three approaches, no copying and pasting between terminals.