One Claude Code agent is genuinely useful. It can take a well-scoped ticket, write the code, run the tests, and open a pull request while you do something else. The temptation is immediate: if one agent is this good, why not run five?
The answer is that running multiple Claude Code agents is not the same problem as running one Claude Code agent. The model handles the code. You handle everything else: which agent works on what, how to keep them from colliding on the same files, how the reviewer knows the PR is ready, how you know anything went wrong. With a single agent, that coordination load is low enough to carry in your head. With four or five agents, it becomes a second job.
The tools described below exist on a spectrum from "open more terminals" to "define a team with roles and let them hand work to each other." Where you land on that spectrum depends on how many agents you are running and how much you want to be in the loop.
The git worktree foundation
Before any tooling, there is one essential concept: git worktrees. If you try to run two Claude Code agents in the same working directory, they will overwrite each other's changes. The standard solution is to give each agent its own worktree — a second checkout of the same repository pointing to a separate branch, sharing the same .git directory so they can see each other's history.
# Create a worktree for a feature branch
git worktree add ../my-repo-feature-a feature/payment-refactor
# Create a second one for another agent
git worktree add ../my-repo-feature-b feature/auth-cleanup
# List all worktrees
git worktree list
Each directory is isolated. Agent A edits files in my-repo-feature-a, agent B edits files in my-repo-feature-b, and neither touches the other's working tree. This is the foundation that every parallel-agent approach builds on — either explicitly, by having you create worktrees manually, or implicitly, by having the tool create them on your behalf.
The worktree itself does not coordinate anything. It just prevents the most obvious failure mode. Every approach after this one is an answer to what you do next.
The DIY approach: tmux + worktrees
The simplest way to run multiple Claude Code agents in parallel is to open multiple terminal panes, navigate each one to its own worktree, and start Claude Code in each. tmux makes this ergonomic because you can split a single terminal window into panes and switch between them without losing session state.
# Start a new tmux session with two panes
tmux new-session -s agents
tmux split-window -h
# In the left pane: navigate to worktree A, start Claude Code
# In the right pane: navigate to worktree B, start Claude Code
This works and costs nothing beyond the API usage you were already paying for. The agents run genuinely in parallel. You can watch both at once.
The problem surfaces the moment you want the agents to interact. Say agent A opens a pull request. Nothing tells agent B to review it. Nothing tells you agent A is done unless you are watching. You become the message bus: reading one agent's output, deciding what it means, and typing something into the next agent's pane. At that point you are not saving time, you are just moving faster inside a tighter loop.
Tmux also does not give you anything around governance. If one agent goes off the rails and starts deleting tests to make them pass, you find out when you look at its pane. There is no budget cap, no quarantine, no audit trail of what each agent decided and why.
For quick experiments — two agents on clearly independent tasks, both scoped to finish in under an hour — the DIY approach is fine. For anything that resembles a real development workflow, you are solving a coordination problem that tmux was not designed for.
Tools that manage parallel agents
Several tools have appeared specifically to reduce the overhead of running multiple Claude Code (and similar) agents side by side.
Claude Squad is an open-source TUI (terminal UI) that manages multiple coding-agent backends, each in its own worktree. It handles the session lifecycle for you: you name an agent, give it a task, and it creates the worktree and starts the session. The interface shows you what each agent is doing without requiring you to juggle tmux splits manually. Because it is open-source, you can inspect exactly what it is doing. The coordination model is still largely manual: you decide when an agent is done and what should happen next, but the bookkeeping is handled.
Conductor and Crystal are Mac desktop applications that take a GUI approach to the same problem. You get a visual interface to launch multiple Claude Code agents, each running in an isolated worktree, with status visible from one window. They lower the friction of spinning up parallel agents considerably, which is genuinely useful if you are the kind of person who prefers a native app to a terminal. The coordination model is similar to Claude Squad in the sense that agents run in parallel but do not automatically hand work to each other. You are orchestrating the sequence.
All three of these tools solve the same problem: parallel agent management. They make it easier to start, monitor, and stop multiple agents at once. None of them — at least in their current forms — solves the handoff problem. When agent A finishes its PR, you still decide when and how to start the reviewer.
From parallel to coordinated: an agent fleet
There is a meaningful difference between agents running in parallel and agents that coordinate. Parallel means they are all doing something at the same time. Coordinated means that what one agent does causes another to act, without you in the middle.
Fleet is built around that second model. It is a single Go binary you install on your machine or a server. No Docker, no cloud orchestration — it runs on your own infrastructure and your source code stays private. It wraps your existing Claude Code agents — it does not replace the model — and gives them an event bus, role-based structure, and a watcher daemon that translates GitHub label changes into agent triggers.
The core pattern looks like this: a developer agent works a ticket, opens a pull request, and adds a needs-review label. The Fleet watcher sees that label, looks up which agent has the reviewer role, and starts that agent. The reviewer runs, posts its feedback, and if it approves, adds an approved label and publishes an event. The release agent picks up that event, checks the approval gate, and merges. You did not type anything after the first ticket assignment.
# Initialize Fleet in a repo
fleet init
# Start the backend team
fleet agent start --team backend
# Start the watcher that fires agents on label changes
fleet watcher start
# Check what everything is doing
fleet status
Each agent runs in its own tmux session, so you can attach to any one of them and watch it work. The difference from the DIY approach is that the handoffs happen automatically through the event bus — Fleet calls it "fabric" — rather than through you reading output and typing into the next pane.
Fleet also handles the governance layer that parallel-only tools leave out. You assign a model to each role: cheaper models for triage agents that just need to classify an issue, a more capable model like Opus for the reviewer or the agent working on a hard algorithm problem. You set a run-time budget per agent — a cumulative cap on how long it can run — so a runaway agent does not keep working indefinitely. A separate 6-dimension evaluation scores each agent, and a distinct risk model flags agents whose operational signals look unusual; when risk hits critical, quarantine can stop them before they cause damage. Every decision gets written to an audit log you can query with fleet log.
There are 120+ agent templates to start from, covering common roles: developer, tech lead, QA, release manager, PM, and others. You can define an org structure in a YAML file that mirrors how your actual team is organized.
Fleet's pricing is free for one agent slot and $49 per slot per month for team use. You can install it from fleetctl.ai.
Which approach fits you
The right tool depends on what problem you are actually trying to solve.
If you have one or two independent tasks: Open two terminals, create two worktrees, start Claude Code in each. The DIY approach costs you nothing in setup time and you are not adding complexity for a workflow you will use twice.
If you frequently manage several parallel agents and want less friction: Claude Squad (if you like terminal tools) or Conductor/Crystal (if you prefer a desktop app) will reduce the busywork of session management. They are easy to try and you stay in control of sequencing.
If you want agents to hand work to each other: This is where Fleet is the right tool. The event-driven model only pays off when you have enough agents and enough recurring handoffs that being out of the loop is worth the setup. A realistic minimum is three roles with a defined handoff pattern: something that opens work, something that reviews it, something that ships it. Below that, the coordination overhead of any orchestration layer is probably more than the problem it solves.
If you care about governance: Budget caps, risk scoring, audit trails, and quarantine are Fleet-specific features. If you are running agents on a shared codebase, giving them access to production systems, or letting them operate for long stretches without supervision, governance is not optional. None of the parallel-only tools currently offer it.
The pattern that causes the most wasted time is starting with the DIY approach, scaling up to five or six agents, and then trying to bolt coordination on top. At that point, the state is scattered across tmux panes, the handoffs are inconsistent, and the audit trail is whatever you can reconstruct from git history. Starting with the right model for the scale you are targeting is faster than retrofitting.
Running multiple Claude Code agents in parallel is a solvable problem. The tools to do it exist, they are ready to use, and most of them are either free or cheap relative to the API costs you are already paying. The question is just how much coordination you need — and whether you want to provide it yourself.