Two or three parallel sessions is the real ceiling

You have just discovered claude --worktree. Two terminals, two branches, no collisions — and the obvious next thought is that if two works, five works better. The tooling agrees with you: nothing in Claude Code caps the number of worktree sessions you can have open, and claude agents will happily show you eight of them at once.

The community's reported ceiling is two or three, and the reason given is not about Claude. It is that every session eventually produces a diff you have to read, and you are the only reviewer.

Treat the number as a review budget, not a session budget

The question to ask before opening a fourth terminal is not "can I keep track of four tasks?" — you can, for about twenty minutes. It is: how many diffs can I actually read carefully in an hour? Run that many sessions. A session whose output you are not reviewing is not progress; it is unmerged work plus a branch you will have to reconcile later.

The failure mode people describe is specific and worth naming, because it does not feel like failure while it happens. Past about three sessions you stop reading diffs and start skimming for whether the tests pass. That is rubber-stamping, and it is precisely the thing parallelism was supposed to buy you time to avoid.

What the docs actually say

The docs describe every mechanism here and make no recommendation about how many worktree sessions to drive at once. They do give a number for the one surface where Claude does the coordinating:

On agent teams the docs say plainly: "Three focused teammates often outperform five scattered ones," and give the reasons as token cost, coordination overhead and diminishing returns. Costs adds "keep teams small," because each teammate runs its own context window.

That is the same shape of argument arriving at roughly the same magnitude — but for a different case and a different reason. In an agent team the lead absorbs the coordination; the cost of one more teammate is tokens and conflicts. In three worktree sessions you are the lead, and the cost of one more is your attention. Nobody official has written down the second number.

Decide merge order before you start, not at merge time

The second half of the practice costs nothing and is worth more than the number itself. Before you launch the sessions, decide which branch merges first, and give each session a set of files it owns.

Worktrees isolate edits, not designs. Two sessions can each produce a clean, green, sensible diff that refactors the same shared module in incompatible ways, and git will not tell you until the second rebase. The docs make the equivalent point for agent teams — break the work so each agent owns a different set of files — and the reasoning transfers directly to worktrees you drive yourself.

A workable rule: if you cannot state in one sentence why two sessions will not touch the same module, they are not independent, and running them in parallel is buying yourself a merge conflict at the price of a context switch.

What is unverified here

Almost all of it. Be clear about what you are being handed:

• The number is one practitioner's self-report, not a measurement, from a write-up on git worktrees with Claude Code. "Practitioners converge on 2-3" is a claim about a conversation, not about a study.
• It is entirely task-dependent. Five independent one-file fixes are easier to hold than two overlapping refactors. The ceiling is set by how much of each diff you must reconstruct in your head, not by the session count.
• Nothing in the tooling enforces it, so there is no error message to discover it by. You find out you exceeded your ceiling weeks later, in the code you approved without reading.

What would settle it is a personal log, not an argument: for two weeks, record how many sessions you had open and how many lines you actually read before merging. You can get the denominator mechanically — this prints every live worktree branch and how large its diff has grown against its merge base:

git worktree list --porcelain \
  | sed -n 's|^branch refs/heads/||p' \
  | while read -r b; do
      printf '%s\t%s\n' "$b" "$(git diff --shortstat "$(git merge-base HEAD "$b")" "$b")"
    done

Run it when you think you are keeping up. If the total changed lines across live worktrees is larger than what you would review in a sitting, the sessions are not the bottleneck — you are, and the queue is already forming.