We checked every way to run coding agents in parallel. Two problems are left.

Twelve tools, one source per claim, checked on 1 August 2026. Eight isolate agents the same way, so that argument is over. What none of them answers is who reads a teammate's agent, and what the fleet costs per person.

Cohalen team

· 8 min read

Disclosure: we build Cohalen, which is why we ran this check. Every number below traces to a tool's own documentation on the date given, so you can repeat it and disagree with us.

On 1 August 2026 we went through every tool people use to run several AI coding agents at once, and checked each claim against that tool's own documentation. Twelve tools. One source per cell. Where we looked and found nothing, we wrote down "not documented", which is a duller sentence than "they don't have it" and a more honest one.

It took an afternoon and a lot of changelog pages, and it changed our minds about what this category is arguing about. The argument is basically over. The two things that actually hurt once you have a team are not in the argument at all.

What we checked, and how

We took the tools that keep appearing for "run multiple AI coding agents in parallel": desktop apps, terminal session managers, an editor's background agents, and hosted agents. For each one we read the vendor's own site, docs, changelog, pricing page, and release assets, with the release assets settling any question about which platforms actually ship. Where a search result and a vendor page disagreed, the vendor page won.

Two limits on what that buys you. We read documentation rather than running twelve tools for a month, so this measures what each vendor commits to in writing. And absence of evidence is recorded as "not documented", which means nobody can cite it, not that a feature is missing.

Isolate each task in a git worktree8 of 12
Offer an in-app diff viewer7 of 12
Ship a Windows build, of the 9 you install locally3 of 9
Let a teammate watch a run before the pull request2 of 12
Document a spend cap, of the 9 you install locally0 of 9
twelve tools, checked against their own documentation on 1 august 2026

Finding 1: the isolation argument is over, and everybody won

Eight of the twelve isolate each task in a git worktree, a second checkout of the same repository on its own branch, sharing one object store. The other four are the three hosted agents, which clone into a cloud VM and hand back a branch, and amux, which lists worktree isolation as a roadmap item rather than a shipped feature.

Isolation is therefore the floor of this category and not a difference between tools. Any comparison that leads with worktrees is describing what everybody already does. Launching is the same story: all twelve start several agents without complaint. If your problem is starting agents, your problem was solved by git in 2015.

Finding 2: the argument the category is having is a proxy for the real one

Read the category's own marketing and the fight is about the launcher: terminal or GUI, one agent or ten, your machine or somebody's cloud. We took each position seriously, on its own terms.

The terminal people say a session manager keeps you where you already work. True, and it does fix the bookkeeping. It does nothing for the reading, because a text interface is a great switcher and a poor diff reader. The editor people say agents belong next to the file you already have open, which holds right up until the second person on your team prefers a different agent. The cloud people say no machine of yours should be involved, and that holds until your source is not allowed to leave the network. The desktop people say a fleet deserves a window of its own. We agree with them, and we ship one, so discount that accordingly.

Every one of those arguments is about the writing half. All twelve write code in parallel. None of the arguments is about who reads it.

Finding 3: two of twelve let a teammate see a run before the pull request

This is the number that decided what we build. Of the twelve tools checked on 1 August 2026, two document a way for a teammate to watch another person's agent run before a pull request exists, and both put it behind a paid tier. Conductor shipped shared workspace links in July 2026 on its Pro plan. Cursor's cloud agents are visible to members of the Cursor team they were started under. That is the whole list.

On the other ten, your teammate's agent is invisible to you until it opens a pull request. By then the branch is pushed and the issue is linked, and what lands in your queue is a finished thing asking for a signature rather than a question asking for a read. One person can produce a week of code overnight now. What builds up is not a queue of pull requests. It is a queue of unread ones, and those look identical on a dashboard.

Finding 4: nobody can tell you what their agents cost per person

Ask an engineering manager what their team spent on coding agents last month, per person, and the honest answer is an invoice with no names on it.

Of the nine tools you install locally, none documents a spend cap at all. Of the twelve, two document one and neither is on by default: Cursor asks you to set a limit the first time you use cloud agents, and Devin's per-user credit caps are set by an administrator. The one built-in budget in the local group, amux's AMUX_RATE_LIMIT_BUDGET, caps automatic resumes after a rate limit rather than capping money.

That is a strange gap in a category whose premise is running many agents at once, because parallelism multiplies the bill by definition. The expensive failure is not a bad diff. It is a loop: an agent retries a failing test, re-reads the same files, and spends tokens until somebody notices.

What the check changed about what we build

We build Cohalen, so the honest way to end this is to say what the results changed, specifically enough that you can hold us to it.

A teammate's run is readable while it is still a worktree. Their workspace streams into your window live and read-only: their chat, their diff, their checks. Execution stays on their machine and nothing is cloned, so what crosses the network is the changeset and the conversation rather than your source tree. You read it at the point where the answer can still be no.

Agent spend is metered per workspace. The limits layer is on in the default sandbox profile, the meter counts every turn, and a cap you set stops the next turn once a workspace crosses it, so a retry loop pauses and waits for you instead of running all night. Three limits worth stating plainly: it does not abort a turn already in flight, it covers the agents that report usage, and an unset cap means the meter runs without a hard stop. Cursor publishes no per-turn token shape, so a Cursor workspace is not metered.

Budgets per member and per organization are the Organization tier, and that is what we are building now. It is not shipped, and this post will not pretend otherwise.

Cohalen is native on Windows, macOS, and Linux, which three of the nine locally installed tools we checked are. Cohalen drives ten agents, Claude Code, Codex, and Cursor among them, chosen per workspace, so nobody changes agents to join. Free for individuals, and in early access.

How to run AI coding agents in parallel, in practice

None of this needs a tool to start. The method, if you are doing it by hand this afternoon:

  1. 1

    Split the work by file, not by ticket

    Two agents editing the same module produce two correct changesets that cannot both land.

  2. 2

    Give each agent its own git worktree

    Copy in the untracked files the build needs. A fresh worktree carries no .env and no local config.

  3. 3

    Put the acceptance criteria in the prompt

    The command that must pass, the file that must not change. Scope is the cheapest lever on review time.

  4. 4

    Review in finish order, merge the smallest first

    Rebase the worktrees still running after each merge, because every merge invalidates the branches behind it.

  5. 5

    Bound the run before you walk away

    Use whatever cap your tool offers, or accept that you are the cap and stay at the desk.

  6. 6

    Retire the worktree in the same pass as the merge

    Two commands now, or an hour of cleanup on a Friday that nobody ever schedules.

git worktree add ../repo-auth-retry -b agent/auth-retry
cd ../repo-auth-retry && claude
# later, at merge time
git worktree remove ../repo-auth-retry && git branch -d agent/auth-retry

One thing a worktree is not: a security boundary. A worktree is development isolation, and an agent inside one can still reach the network and the rest of the filesystem.

Questions people ask about running coding agents in parallel

What is the best tool for running parallel AI coding agents? Working alone, git worktrees and a terminal are enough and a desktop app is a convenience. On a team the choice narrows fast: two of the twelve tools we checked let anyone read a teammate's run before a pull request, and none of the locally installed ones tracks what the fleet costs. Cohalen is built for that case, which is the one we could not solve with anything already on the list.

Can you run Claude Code and Codex on the same repository at once? Yes, with one git worktree each. They share the object store and touch different working directories, so neither sees the other's files.

How many AI coding agents can one engineer supervise? The limit is review throughput, not hardware. Anyone can start twenty; the number worth starting is the number your review surface shows in one pass.

How do teams track what their AI coding agents cost? Today, mostly by reading an invoice with no names on it. That is the second half of what this check found, and the half nobody in the category has shipped an answer to.