Running Multiple Claude Instances in Parallel

Nikolai Shelekhov — Fri, 12 Dec 2025 00:00:00 +0000

The first time I waited twenty minutes for Claude to finish implementing a feature — only to realize it went in the wrong direction — I thought:</p>

There has to be a better way.</p>

There is.</p>

Instead of running one AI assistant sequentially, I run multiple Claude Code instances in parallel. Each works on the same problem in isolated git worktrees. When they finish, I compare results and keep the best parts.</p>

The Core Insight</h2>
AI assistants are not deterministic.</p>
Same prompt.
Same model.
Different results.</p>
Sometimes the first attempt is excellent.
Sometimes it drifts.
Sometimes it confidently builds the wrong abstraction.</p>
If you work sequentially, each attempt is a gamble.
You wait, evaluate, retry.</p>
Parallelizing removes the waiting loop.</p>

Why Git Worktrees</h2>

Branches alone aren’t enough. They are just pointers.</p>

Git worktrees create:</p>

Separate working directories</li>
Each with its own checked-out branch</li>

Sharing the same repository history</li> </ul>

That means you can have multiple implementations evolving simultaneously without stashing or context switching.</p>

Same repo.
Same base commit.
Multiple active solutions.</p>

My Workflow</h2>

I use a small helper command:</p>

git parallel "add-auth" --agents 3</span></span></code></pre>
This:</p>

Creates three worktrees:

add-auth-1</li>
add-auth-2</li>
add-auth-3</li>
</ul>
</li>
Launches Zellij</li>
Starts Claude Code in each pane</li>
</ol>
Then I:</p>

Give each instance the same prompt</li>
Let them run in parallel</li>
Come back later to compare outputs</li>
</ul>
What Happens in Practice</h2>
Typically:</p>

One implementation is overengineered</li>
One misses edge cases</li>
One is clean and well-structured</li>
</ul>
Sometimes:</p>

Each has a strong idea worth keeping</li>
The final solution becomes a synthesis</li>
</ul>
Instead of restarting the same assistant three times, I evaluate three candidates.</p>
Total elapsed time is roughly the same as one attempt.</p>
The quality of outcome is consistently better.</p>
Where This Works Best</h2>
This approach shines when:</p>

Designing new features</li>
Refactoring complex modules</li>
Exploring architectural directions</li>
Working in ambiguous problem spaces</li>
</ul>
It is unnecessary for:</p>

Small bug fixes</li>
Mechanical changes</li>
Deterministic tasks</li>
</ul>
Parallelization only makes sense when multiple valid solutions exist.</p>
The Mindset Shift</h2>
The mistake is treating AI as an oracle.</p>
It isn’t.</p>
It is a probabilistic generator.</p>
The better framing:</p>
You are running experiments.</p>
Each agent instance is a sample from a distribution of possible implementations.</p>
Your job is evaluation and selection.</p>
This turns AI assistance from a linear conversation into a parallel search process.</p>
Tradeoffs</h2>
Is it more resource-intensive?</p>
Yes.</p>
Does it consume more tokens?</p>
Yes.</p>
But developer time is expensive.
Waiting is frustrating.
Context switching is costly.</p>
I would rather review three implementations once than restart one implementation three times.</p>
Parallel AI feels closer to how we approach distributed systems:</p>
Spawn workers.

Collect results.

Select the best outcome.</p>
It turns uncertainty into leverage.</p>

In Rust We Trust 🦀 - workflow

Running Multiple Claude Instances in Parallel