Running Claude Code sessions in parallel

There are a lot of pages that will tell you how to start a second Claude Code session, and the mechanics genuinely are that easy: open another terminal, git worktree add so the two aren't fighting over the same checkout, run claude in each. If that's all you needed, you're done, and you don't need this page.

This page is about what happens after that. I run twelve to fifteen sessions on a normal working day, and the four-engineer team I lead at F-Secure has each engineer running eight to twenty streams, so the team merged 844 pull requests out of 892 opened in June 2026. Getting to three sessions took me a weekend of common sense. Getting past six took months, and every one of the things below is something that broke on me first and got fixed afterwards.

The curve isn't smooth. One to three parallel sessions is a mild extension of normal work. Somewhere between four and eight the coordination overhead changes shape, and the techniques that got you to three actively stop working. Past ten you need agents watching your agents, which sounds like an affectation until you try to hold twelve streams in your head for an afternoon.

1. Two sessions in one directory

The first thing that breaks, and the easiest to fix. Two agents working on different branches cannot share a checkout, because checking out one branch evicts the other, and what you get is dropped uncommitted work, a dev server pointing at files that changed underneath it, and an agent that's confused about why its own edits vanished.

Use worktrees. Claude Code has first-class support for them, and cctabs passes the flag through when it spawns a tab:

cctabs new auth-fix ~/Dev/myapp --worktree

The gotcha worth knowing in advance, because it cost me an afternoon: a fresh worktree branches from whatever your remote-tracking branch points at, which is not necessarily your current HEAD. If you have local commits you haven't pushed, the new worktree can quietly branch from the older remote tip and miss them, and the agent then spends an hour re-solving a problem you already solved. After spawning, check the base:

git -C ~/Dev/myapp/.claude/worktrees/auth-fix log --oneline -1

Read-only sessions don't need a worktree. Anything that will edit code on its own branch does.

2. You become the routing layer

This one arrives around five or six sessions and it's the one people don't see coming. An agent in one tab works something out — an API behaves differently than the docs claim, a migration has to run in a particular order, an approach was tried and doesn't work. Two other tabs need to know. At three sessions you just remember it and re-explain it in each tab, and that feels fine, so you keep doing it. At eight sessions you are a message bus made of meat, and you are the slowest component in your own system.

What replaced it for me is a rule that sounds too simple: the repo is the bus. When something matters across streams it gets committed as markdown before I move on, in a place the other agents already read — a decision note, a LEARNED.md, a line in CLAUDE.md. Thirty seconds of writing now instead of re-explaining the same finding across eight tabs later. When it only matters to one stream, it stays in that stream and doesn't get written down at all, because a repo full of notes nobody needs is its own problem.

Live state is the harder case, and that's what cctabs scrollback and cctabs send are for: one session can read another's terminal directly and hand context across at runtime, without you carrying it.

3. Scanning instead of deciding

At ten streams, checking each one every few minutes is forty context switches an hour, and it produces almost no information, because most of the time the answer is "still working." You'll do it anyway, because the running-stage instinct says an unwatched agent is an agent going wrong.

Two things fix it. The first is a schedule instead of an impulse: scan the fleet every fifteen to thirty minutes with cctabs sessions, and between scans leave the streams alone unless one has surfaced something. When you do bring a stream forward, you're there to do one of four things — approve and send it back, correct its course and send it back, break the remaining work into smaller pieces, or close it because it's done or no longer wanted. If you're not doing one of those, you're just looking, and looking costs you the thread you were on.

The second is a meta-agent. Past ten streams I have a sweep skill that reads every session's scrollback, classifies each one as working, blocked, quiet or stuck, and hands me a short triage list with a drafted reply for each blocked session. I read the list and decide; I don't scan. The sweep drafts and surfaces, and I'm the one who sends, because letting a meta-agent reply across the fleet on its own introduces silent failures I can't see. The Course covers how to build one.

4. The quota window closes at 3pm

The ceiling on fleet practice today isn't capability, it's quota. Run ten sessions hard for a couple of hours and you can hit the tokens-per-window cap in the middle of the afternoon, which is a specific and annoying kind of stuck.

Most of the fix is upstream of the wall. Briefing an agent properly costs thirty seconds and saves it a chain of expensive context-building tool calls where it greps the whole repo trying to work out what you meant. Encoding a pattern in a skill or in CLAUDE.md stops every new session rediscovering it. Asking the same question in two sessions costs you twice for an answer you already had, so the finding gets shared across rather than re-derived. And an agent retrying the same broken approach five times is burning the window with no progress, so pulling it forward early is a quota decision as much as a quality one.

When the window does close, route a couple of low-stakes background streams to another backend and keep going. Exploratory refactors, boilerplate you'll review heavily anyway, and read-heavy analysis all travel fine. Production code on the critical path and hard debugging don't, and tool-use-heavy work gets flaky on smaller models, so keep your capability-sensitive streams on Anthropic and shed the rest.

5. Brain-fry, which is the actual ceiling

Most "I can't run more than four sessions" stories are not capability stories. They're brain-fry: the particular fatigue that comes from running too many parallel streams on the wrong substrate, and it's the reason people plateau where they do.

What causes it, roughly in order: trying to supervise ten contexts instead of reading ten contexts off the tabs; briefs so vague that agents go in circles and drag you back in to find out why; mixing deep architectural work and mechanical CI fixes in the same fleet, because the gear-shifting costs more than either does alone; working past the hours you can actually sustain, since fleet practice expands what fits in an hour but doesn't add hours; and not standing up, which matters more at this scale rather than less.

What doesn't cause it is worth saying too, because people misattribute it constantly. A slow model causes impatience, not brain-fry. Hard problems don't cause it, and can be pleasant. The raw session count doesn't cause it either — a well-organised twelve-stream day is calmer than a badly organised four-stream one.

When it hits, stop pushing for fifteen or thirty minutes. Walk somewhere, or close two or three streams to bring the count down to what the current version of you can hold, or switch to single-stream work like code review or writing, which is genuine recovery for fleet brain. Pushing through is the common response and the wrong one, because brain-fry is information about your fleet's structure and it doesn't stop being true when you ignore it.

6. Review load, which becomes someone else's problem

The thing nobody warns you about: if your parallelism works, you have created a review queue. One engineer running a real fleet can put more PRs in front of a team than the team has any way to read line by line, and the bottleneck moves from writing the code to being confident in it. Anthropic have said the same thing about their own engineering, and their published numbers move in the same direction as ours.

That's a big enough subject that it has its own post: code review when four engineers merge 844 PRs a month, including the per-PR triage we ran on a full month to check whether the volume was real.

What a day actually looks like

One to three streams have my attention at any moment, and those are the ones with a dev server I'm clicking through, a browser automation I need to eyeball, or a conversation where the problem needs me. Everything else has my trust rather than my attention: briefed, running, checked on a schedule. The whole practice is the discipline of keeping those two groups separate, and the tooling only exists to make the separation cheap.

If you want the long version, the Course is six weeks of this, free and self-paced, with the assignments meant to be run against your own repo. Week 2 is the tooling and Week 5 is the part about letting go, which is the one that actually decides whether this sticks.