How do you run multiple AI coding agents in parallel?
Give every agent its own checkout of the repository, so two agents can never edit the same file at the same time. Git worktrees do this on one machine and cost nothing. Containers do it with more isolation, since each agent also gets its own processes, ports and installed tools. Then run each agent against its own branch and merge the results one at a time, reviewing each.
What is true regardless of what you pick
- The failure mode is shared state, not model quality: two agents in one working tree overwrite each other's edits and produce a build that neither of them broke.
- A git worktree is a second checkout of the same repository on a different branch, sharing one .git directory. Creating one is a single command and costs the size of the files, not the history.
- Worktrees isolate files. They do not isolate installed packages, running dev servers, ports, environment variables or databases, which is where parallel runs collide next.
- Practical limits are human before they are technical. Reviewing the output of ten agents takes longer than running them, so throughput is capped by how fast changes get read.
- Every agent CLI in common use (Claude Code, Codex, Grok, Kimi, Gemini) will run as several processes at once. None of them isolate each other by default.
Your options, and where each one stops
| Approach | Good for | Breaks when |
|---|---|---|
| Several terminal tabsRun each agent CLI in its own terminal, all pointed at one checkout. | Two agents working on obviously separate areas, for an hour, when you are watching both. | Anything touches a shared file, or one agent runs a formatter across the tree. There is no isolation at all, so the first collision is silent and shows up as a broken build later. |
| Git worktrees, driven by handOne checkout per agent on its own branch, created with git worktree add. | Most people, most of the time. It removes the file collision, which is the majority of the pain, and requires no new software. | Agents need to run the app. Two dev servers want the same port, two test runs want the same database, and installed tool versions are shared across every worktree. |
| A terminal multiplexer over worktreestmux or a wrapper around it, giving each agent a pane and a worktree. | Watching several agents at once on one machine, and reattaching to them after an SSH session drops. | You want to check on them from a phone, or the machine is your laptop and you need to close it. The session survives a disconnect but not a shutdown. |
| A container per agentEach agent gets its own filesystem, processes, ports, package versions and credentials. | Agents that install things, run services, migrate a database, or hold credentials you would rather not share between tasks. | The work is a one-line fix. The setup cost is real and a worktree would have done. |
| A hosted cloud agent serviceThe vendor runs the agents on their infrastructure and shows you the results. | Getting parallel work immediately with nothing to operate, and for teams who would rather buy the plumbing. | Your code, your keys or your data cannot leave your infrastructure, or the per-seat cost stops making sense as usage grows. |
What to actually do
Start with git worktrees. They solve the collision that actually bites, they cost nothing, and you will find out within a day whether you need more.
Move to a container per agent when the agents start needing an environment rather than just files: installing packages, running a dev server, holding a database password, or touching a system you do not want every task to reach.
That second step is what intentic packages. Each agent gets a Docker sandbox on a machine you own, with its own worktree inside it, its own installed tools, and its own credentials. It is free and MIT licensed, so the way to evaluate it is to run it rather than to read about it.
Why parallel agents break: shared state, not the model
Two agents pointed at one checkout will eventually write to the same file, and the second write wins silently. Nothing errors, and the damage surfaces later as a test failure neither agent caused, in a file neither of them was asked to change.
This is why isolation comes before orchestration. A dashboard that shows you six agents running is worth very little if all six share a working tree. The first decision is what each agent is allowed to see and change.
- One checkout per agent removes file collisions.
- One branch per agent keeps the history readable and makes each result reviewable on its own.
- One container per agent additionally removes port, package, process and credential collisions.
How many agents is realistic
The ceiling is review capacity. Agents produce changes faster than anyone reads them, so the useful number is the number whose output you can actually get through, which for most people is somewhere between three and six on real work.
Cost is the second ceiling and it is easy to underestimate, because parallel agents multiply token spend at the same time as they multiply output. Watching per-agent spend from the start is worth more than tuning the count.
Merging without a queue of conflicts
Land one agent's work at a time and rebase the rest onto the result. Agents that all branched from the same commit will each be slightly stale afterwards, and rebasing before review keeps the conflicts small and attributable.
Splitting work so that two agents rarely touch the same directory removes most of this problem before it starts. Task boundaries that follow module boundaries are worth more than any merge tooling.
What to give each agent beyond files
Once agents run the code rather than only editing it, they need an environment each. That means their own ports, their own database, their own installed language versions, and their own copies of whatever credentials the job needs.
This is the point where worktrees stop being enough and a container per agent starts paying for itself. It is also the point where credential handling stops being theoretical, because an agent that can reach production with a shared key is a real risk rather than a hypothetical one.
Related questions
How many AI coding agents can you run at once?
Technically as many as your machine has memory and your provider allows. Practically the limit is how fast you can review what they produce, which puts most people between three and six agents on real work. Running more usually means the extra output is merged without being read, which removes the point of running agents at all.
Should each agent get a git worktree or a container?
A worktree if the agents only edit files, because it is one command and no new software. A container if the agents also install packages, run a dev server, use a database, or hold credentials, because worktrees share all of those and containers do not.
Can two agents work on the same repository at the same time?
Yes, provided each one has its own checkout and its own branch. Two agents sharing a single working tree will overwrite each other's edits with no error, so the isolation has to come first. Git worktrees are the cheapest way to give each agent a separate checkout of the same repository.
Can you run different agent CLIs in parallel, such as Claude Code and Codex?
Yes. They are separate processes with separate accounts and they do not know about each other, so mixing them is a matter of isolating their working directories like any other parallel run. Some people deliberately give the same task to two different models and compare the diffs before picking one.
Does running agents in parallel cost more?
Yes, roughly in proportion to how many are running, since each one consumes its own tokens. The saving is wall-clock time rather than money, so it is worth tracking spend per agent from the first day rather than discovering the total at the end of the month.
Read next
Written against the state of the field in 2026-08. This area moves fast. Spot something out of date or wrong? Open an issue and it is fixed in the next build.