Branch per agent: when you are the only reviewer

Running several coding agents at once used to take work: dividing the work, juggling handoffs, and stitching the results back together. This month Claude Code started doing that part for you. Now the constraint is you.

What shipped

On September 17, Anthropic redesigned projects in Claude Code. You select a goal and a repo or other context, and a coordinator directs threads while Claude routes the work into them. The post puts the mechanics plainly: “Under the hood, each thread is a Claude Code cloud session working on its own branch and copy of the repo.” When two threads touch the same code, the overlap is resolved as a merge conflict, like any other pull request. Threads also add to and draw from a shared project memory.

It is a beta for select Pro and Max subscribers who use cloud sessions in Claude Code and do not already have projects on the web or desktop, with wider access planned. Anthropic also warns that because each thread is a full Claude Code session, projects can reach usage limits faster, and it lets you choose the model and effort level for the coordinator and for the worker threads separately.

On the OpenAI side, Big Hat Group’s weekly roundup notes Codex SDK 0.155.0, released September 18, which added archiving and deletion for tasks in the Codex CLI’s agent view, plus an experimental voice mode. The same roundup flags a deadline: GPT-5 retires on October 14 for ChatGPT and for Codex used through a ChatGPT account. On the API, the roundup says the GPT-5.5 transition does not apply directly to API-based integrations, and it also tells readers to move to GPT-5.6-sol or an equivalent configuration in APIs or SDKs.

Why review is now the constraint

A team of one has one reviewer. Agents can open pull requests as fast as you can describe work, but each one still has to be read by someone who understands the code and owns what reaches production. If you run more threads than you can review with care, one of two things happens. The queue grows and branches go stale and start to conflict. Or you start approving without reading, which is how debt and bugs get in.

So the useful question is not how many agents the tool allows. It is how many diffs you can read properly.

A decision rule for thread count

Work it out from your own numbers:

1. Time your last five real reviews of agent pull requests, start to finish, including running the change. Take the median.
2. Decide how many hours a day you will actually spend reviewing. Be honest; it is usually less than you think.
3. Divide. That is your daily merge capacity.
4. Run no more threads than you can clear in a day. If branches are waiting more than a day for you, cut the thread count before you cut review depth.

A worked example, with made-up numbers: if a careful review takes you 20 minutes and you will spend 2 hours a day on review, you can clear about six pull requests. Six parallel threads that each open one PR a day is the ceiling. If each thread opens three, you are down to two threads. Your own figures will differ; the arithmetic does not.

A merge gate for agent branches

Make these true before anything merges, whoever wrote it:

• One purpose per branch. If the diff does two things, send it back to be split.
• Tests came first, or came with it. A behavior change without a test that would have failed before it is not done.
• CI is green on the branch, rebased on current main. Not green on a stale base.
• You can explain every changed line. If you cannot, you do not merge it; you ask the agent to explain it or cut it.
• No new dependencies you did not ask for, and no secrets, keys or config values in the diff.
• Conflicts resolved by reading both sides, not by accepting whichever branch finished last.
• A short note on what the agent got wrong, added to your instruction file if it will happen again.

The last item is the one that compounds. Every correction you write down is a review you will not have to repeat.

What to do this week

• Pick one task with a clear test and run it as two or three parallel threads, not ten. Measure how long your reviews take.
• Set your thread count from that measurement, using the rule above.
• Paste the merge gate into your pull request template, so every agent branch meets the same bar.
• If you use Codex through a ChatGPT account, check which model your workflows pin and move off GPT-5 before October 14.
• Check project usage after a day of parallel threads. Each thread is a full session, so projects can reach usage limits faster.

Parallel agents are cheap to start. The engineer who reads the diffs is the scarce part, so plan around them.