Run 10 Claude Code Instances in Parallel — From Your Phone
The trick is the daemon. Spawn each agent on whatever machine has the right files; supervise from one screen — your phone counts. Use git worktrees per agent so they don't fight over node_modules. Sandbox each one to its workspace. Approve permissions with haptics.
The first time someone runs 10 Claude Codes in parallel and pastes the result on Twitter, it sounds like a stunt. Then you actually try it on a real bug list and you realize: 6 of 10 finish; 2 ask for permission; 1 got stuck; 1 produced a beautiful PR. The math works out.
Anthropic's Agent Teams handles within-session parallelism (sub-agents on one machine). For cross-machine parallelism — different boxes, different repos, different GPUs — you need a daemon on each machine. The phone is then the spawn point and the approval surface.
Recipe: 10 agents, 1 morning
1. Pre-stage worktrees
cd ~/code/myproject
for i in $(seq 1 10); do
git worktree add ../myproject-$i $(git rev-parse HEAD)
done
One worktree per agent. They don't fight over node_modules, generated files, or each other's commits.
2. Pre-stage tasks
One file per task — ~/tasks/01.md through ~/tasks/10.md. Each is two paragraphs of intent: "find every place this hook is mis-typed and fix it" or "convert this React class component to a function component, no behavior change."
3. Spawn from your phone
Open the Celistra mobile app. Tap Spawn. For each task:
- Host: pick the machine with the GPU (if the task needs one) or the laptop (if not)
- Working directory:
~/code/myproject-1 - Command:
claude --resume task-1 < ~/tasks/01.md - Auto-restart: on (tasks crash sometimes, the agent often recovers)
- Sandbox: default — workspace + network + subprocess + read everywhere
10 spawns in 90 seconds.
4. Watch the fleet
Fleet view: 10 rows, one per agent. Each row shows runtime, last 80 chars of output, status. Tap any row to attach to its PTY.
5. Approve permissions with haptics
An agent asks "can I run git push origin task-3?". The phone buzzes. Long-press to approve, swipe to deny. The agent continues. Total time elapsed in your day: 2 seconds.
6. Pull results
When an agent finishes, its worktree has a branch with the work. From your laptop:
for i in $(seq 1 10); do
cd ~/code/myproject-$i
if git diff --quiet HEAD~1 HEAD 2>/dev/null; then
echo "Agent $i: nothing"
else
echo "Agent $i: $(git log --oneline -1)"
fi
done
Cherry-pick what worked. Throw away what didn't.
Why 10, not 100?
The dev.to multi-agent orchestration writeup landed on the same number empirically: most effective teams run 2–5 agents in parallel, with a soft ceiling around 10. Beyond that, coordination cost dominates. The constraint isn't compute (you're paying Anthropic per token, not per process); it's that you have to actually triage 10 PRs.
Why this needs a daemon
10 ssh sessions to 5 hosts means 10 terminal windows on your laptop. The fleet view collapses that into one screen. The 64KB replay ring per agent means you can drop in mid-task without losing context. The audit log means "what did agent 7 actually do?" is a query, not an investigation.
Why this is a phone use case
The phone is a worse keyboard than your laptop. It's a better notification surface. Spawn from the laptop in the morning; the phone is your "permission approval + status check" while you're walking the dog. The mobile app's haptic approval flow is the difference between "agents kept working" and "agent waited 90 minutes for me to come back to my desk."
FAQ
Doesn't this cost a fortune in tokens?
Each Claude Code instance bills against your Anthropic plan. 10 in parallel for an hour costs roughly 10x what one for an hour costs. The math is whether 10 in parallel deliver more than 10x the value of one. For triaging unrelated tasks: yes. For collaborating on one task: usually no — coordination dominates.
How do agents avoid each other's worktree conflicts?
They can't fight over the same files because they're literally in different directories. They could push the same branch name; the auto-restart and the daemon's command record let you re-derive who pushed what.
What if a permission request is asked twice — on the laptop and the phone?
First responder wins. The daemon issues the permission token; once consumed, it's burned. Subsequent prompts get a 'still waiting' state until the agent makes a new request.
Does this work with Cursor / Aider too?
Yes. The daemon doesn't care what process it's spawning. Aider in particular benefits — its design assumes one repo per session, which the worktree pattern provides.