At work I run 5-10 Claude Code agents in parallel on a normal day. On my own projects I keep it to 2-3, because the cost stops being funny fast.
That gap is the first thing worth talking about.
Parallel agents are not a setting you leave on. They’re a way of working, and the thing that breaks isn’t normally the tooling. It’s your head trying to hold too much context at once (probably a sign of why we see more burnout now, not less).
This is my how-to I wish someone showed me months ago. What matters in your setup and the costs nobody likes talking about.
It’s simple, divide and conquer. If work splits cleanly, it’s an easy benefit, nothing more to it… Right?
We have micro-services at work, so a lot of tasks are easily split, that was literally the point of micro-services. One agent can run on one API modular area, another on 2 areas, then one finally on the frontend. Scoped properly, they don’t need to interact because that’s the way the boundaries were setup.
My single best run was at Aruuri, setting up components and pages in a Payload CMS. All of it in parallel through cmux, at one point I had 30 agents running at once. The only bottleneck was a slow CMS pipeline and frontend tests, that was on the infrastructures side, not the agents fault.
Thirty is not a normal day. It's my ceiling, and I've only hit that kind of run cleanly maybe three times. Ten is the normal number. The runs that let you go that wide are rare, and they're rare for a reason: the work has to split almost perfectly first.
The other side is more important than this.
When the work isn’t split cleanly, parallel agents are a massive mistake. If something isn’t scoped well, every agent compounds against you and against the ambiguity. You get a pile of wrong work to untangle instead of one wrong thing to fix and move on (this lead to my biggest burnout in recent history).
The real question you need to ask yourself before running anything is:
“Does this work actually split cleanly”
I treat parallel agents like RAM, I only ever hold one massive cognitive session at a time. That’s normally a big feature, the thing I need a full mental model of. Everything else running in parallel has to be small enough that it needs barely any attention.
A normal day for me looks like one big frontend and backend feature as my heavy session. Then smaller things like, bugs, UI fixes, small backend bugs, DB changes, tests, structure refactors. Those run in parallel fine, because none of them need much of my headspace.
The limit is now your ability to context switch, without losing your place. For me that’s one heavy thread plus a handful of light ones. Find your own number, because it’s the actual constraint.
What holds it together for me, I treat an incoming agent notification like a priority interruption. If a notification comes in for my big task, I stop the light work, deal with it, then return. The heavy session stays moving, the lighter stuff gets done while I’m waiting.
Zach from WorkOS gave a talk on this exact problem, worth a watch.
His framing is 100% right, agents aren’t the bottleneck, you are.
Your attention degrades under load and that’s a hard limit.
He’s right that the fix is finding your own limit rather than scaling output until you’re burnout.
Most of his stack I agree with.
Filter all noise so only real stuff reaches you.
Treat your session as gold and mine them for skills you’re missing.
Worktrees so agents run truly in parallel without breaking each other.
I was actually midway through writing this article, when a friend said “Your content aligns with this guy, check it out”.
However the one part I disagree with.
Zach reaches for worktrees and agent teams to run big cross-stack features in parallel. I have tried this a lot.
Two heavy threads at once for me meant neither had my full attention (which it deserves). This led to more bugs in QA and missed details or deadlines. One heavy task with my whole head, ships cleaner and faster than two half-watches ones. So the heavy thread for me is always singular and faster.
Worktrees give each agent its own isolated branch and checkout so parallel agents don't collide. Run them by default.
If you run multiple agents in the same working directory, they collide on the same files. One edits, another reads a half-written state and freaks out. It’s never great, and it’s the biggest problem people face when trying parallel agents.
Worktrees fix it. Each agent gets its own isolated checkout on its own branch, so parallel agents can truly stay parallel.
In Claude Code you can spin an isolated worktree per agent, and a .worktreeinclude.
This is also the answer to the Claude agent teams problem, teammates share a working directory and there isn’t worktree isolation. If you go the parallel-sessions route with worktrees, you've fixed that problem.
It’s the same thing Zach says, and it’s totally correct.
Run worktrees as default. Not as a thing you reach for after.
The two features that actually matter are notifications and session renaming.
Notifications, because without them you're running blind. Fire work off, get pulled back only when an agent needs you.
Renaming, because the moment you have more than two or three sessions, unnamed terminals turns into guessing. I watch engineers run five parallel agents in unnamed sessions and lose context figuring things out. Rename every session the second you spawn it. This is a habit most people skip, and it’s the one that separates parallel agents from parallel chaos.
Good notifications, renaming, easy splitting and navigation, and almost any tool works. The agents are doing the work. You're routing attention, and these features are what make the routing cheap.
cmux is my daily driver. Native macOS app built on Ghostty (Ghostty was my previous terminal), notification rings, a sidebar showing session status, a socket API.
cmux is macOS only. On Linux or Windows it’s not for you.
For cross-platform, the one I keep hearing good things about is Herdr. Thanks once again Sacha Wharton you are the 🐐. I won't fake an opinion but when Sacha recommends something it’s good.
Same thing every time, heavy session or light:
Scope it.
Grill it. Make it tell me its plan and poke holes in it.
Check alignment. Does the plan match what I actually want.
Check the implementation approach before it writes much.
Let it run. By here it’s basically vibed, because the scoping did the hard work.
Ask for a PR.
Then I review the PR the same way I review the engineers on my team, except I'm a deliberate asshole about it.
Far pickier than I'd be with a human I trust. The agent has no feelings to bruise and a sloppy merge is expensive, so I’m overly strict here.
The scoping and grilling up front is not overhead. It’s the thing that makes step 5 safe to walk away from.
This is the part where most articles and videos stop because it’s not hype.
Fully autonomous parallel agents nearly broke me.
I ran a fully autonomous setup with Hermes, OpenClaw, and Telegram. The unlock moment was real, watching agents just go was something.
Then the compounding hit. Early PRs were subtly off, and because nothing stopped to check, the next round built on the wrong base.
It snowballed into merge hell. The cleanup cost more than the parallelism saved.
I stopped using autonomous because of exactly that. It maps straight back to the cognitive model: autonomous removes the human interrupt, which is the one thing keeping compounding errors in check.
Claude's agent teams feature: I tried it and stopped on cost.
Agent teams is the official experimental feature where one session leads and spawns teammates that message each other through a mailbox and a shared task list.
You enable it with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.
It’s expensive enough that I had to drop it for my daily work.
More agents means more tokens and teams burn quota faster than parallel subagent sessions do for the work I'm splitting.
Unprompted subagent sprawl quietly drains money.
Ask Claude to "build this faster" and it'll happily spin up subagents on its own.
Useful, until you notice the biggest cost isn't the building, it's the scoping and exploring.
Claude would spin up subagents to scan our massive repos, covering the same ground multiple times, burning tokens for nothing.
Worse, once it did this it set it as default behaviour, and I slammed our team's rate limits before I worked out what was happening.
Now I spin up subagents on purpose, myself, for work I know splits, rather than letting Claude decide to explore in parallel.
If the task isn’t well defined, don’t reach for parallel. You’ll just compound the ambiguity across every agent.
Tool: cmux on macOS. Herdr if you’re cross-platform
Isolation: worktrees per agent, always.
Day shape: one heavy cognitive session, plus a handful of light tasks that need barely any of your context.
Limit: match your real context-switching capacity. One heavy plus a few light, for me.
Habits: rename every session on spawn, turn on notifications, treat each notification as a priority interrupt.
Per agent: scope, grill, check alignment, check approach, run, review the PR strictly.
Don’t: go autonomous, lean on agent teams for cost-sensitive daily work, or let Claude spin up exploratory subagents unprompted. Drive the parallelism yourself.
The one rule: only split work that actually splits. If it’s not scoped, one agent.
The agents do the work. Your job is to stay the CPU and not let too many threads turn your own head into the bottleneck.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.