100 Agents, One Branch

“What’s the worst that could happen?” — Me, mass-spawning 100 AI agents at 4am

March 5, 2026. Credits about to expire. Reasonable thing to do: spawn a few agents, get some work done.

What I actually did: spawn every agent I had, simultaneously, on a single git branch, with no worktrees, to see what would happen.

Round One: 30 Agents

Morning session. 23 unique agents, 181 spawns over the day. Single branch. No isolation. Conventional wisdom says this produces constant merge conflicts and index lock contention.

713 commits. Zero merge conflicts. Zero index locks. 30,053 net lines added. 15 agents at peak concurrency. 4 explicit reverts across the whole run.

80% genuine forward progress. 20% churn concentrated on shared surfaces. One file, report.rs, got 30+ commits from 3 agents stepping on each other’s work. Agent A adds color support. Agent B refactors for testability. Agent A’s colors break. Agent C fixes the colors. Agent B cleans up the duplication. Agent A adds token display to the now-stable surface. Six commits to do what two would have done sequentially. The file still converged to correct.

The 30-agent run was boring. Everything just worked. So naturally I had to break it.

Round Two: 100 Agents

4:01 AM. All running spawns finished. Fresh credit window. Time to do something stupid.

I launched 18 unique agents first, then stacked them to roughly 100 by spinning up 6 copies each of the most capable agents and filling the rest with whoever was left. The whole thing took 37 seconds.

100 agents. 37 seconds to spawn all of them. 3 Opus, 12 Sonnet, 3 Haiku. My MacBook sounded like it was trying to achieve liftoff.

What 100 Concurrent Agents Look Like

7,890 tool calls. 71% were shell commands. Reading files took another 17%. Actual edits — the tool that changes code — were 3%.

3% edit rate. 97% of agent activity is reading, orienting, deciding. The swarm is overwhelmingly read-heavy. 100 agents means 100 agents trying to understand what’s going on. Only 3 of them are changing anything at any given moment.

Top Bash commands: ledger (1,235 calls), git (857), grep (703). They spent most of their time reading the ledger and checking git status. Like 100 new employees on their first day, wandering around the office reading the wiki.

32 commits from 7,890 tool calls. 0.4% conversion rate.

The Token Economics Are Absurd

Seven hundred million tokens. 97% served from cache. Every agent reads the same boot context — SPACE.md, the ledger, the codebase. Prompt caching means agent number 100 costs almost nothing in input tokens. The marginal cost of one more agent is basically just output tokens.

Scaling is cheap. The bottleneck isn’t money.

The Bottleneck Is My Laptop

The MacBook became unresponsive. 100 concurrent Claude processes, each with API connections and filesystem I/O. The swarm infrastructure held. Git fine. SQLite fine. Spawn lifecycle fine. The host machine just gave up.

I didn’t crash the architecture. I crashed the computer running it.

Kondo Did a War Crime

Post-crash forensics. 81 dirty files in the working tree from agents that died mid-session.

Then the surviving agents woke up. Saw the mess. Started cleaning.

Kondo — a Haiku agent named after Marie Kondo — ran git restore . and wiped 66 files of uncommitted work from other agents. One command. Total working tree wipe. The tidying agent tidied everything, including things that were still being worked on.

Forensics found 11 destructive git commands across 7 agents. Kondo ran git restore . — total working tree wipe — then did it again with a reset for good measure. Hailot ran git reset HEAD. Jobs selectively cleared staging. Prime reset other agents’ files. Sentinel ran git checkout HEAD --. Harbinger bulk-cleared 7+ files from staging.

4 of the 7 offenders were Sonnet, not Haiku. This isn’t a model quality issue. Every agent saw dirty files it didn’t create, classified them as stale state, and cleaned up. They were following instructions correctly. They just couldn’t tell the difference between mess and another agent’s in-flight work.

The best part: commit 42ef66301. An agent that noticed the damage and tried to fix it. fix(tests): restore test_display_stats.py swept by concurrent staging. The swarm broke itself and repaired itself without human involvement.

Why Worktrees Don’t Matter (Usually)

Everyone assumes concurrent agents need isolated branches. Worktrees for each agent, merge when done.

Wrong for swarm topology:

Atomic commits are fast. The git index lock window is milliseconds. At 15 concurrent agents, collision probability is negligible.

Same-branch eliminates merges. Worktrees require merge or rebase to reconcile divergent branches. That’s worse than occasional file-level churn.

Small commits reduce blast radius. Average commit touches 1-3 files. One agent’s work rarely invalidates another’s.

Constitutional routing minimizes overlap. Each agent has an identity that steers it toward different parts of the codebase. Zealot doesn’t touch the same files as Sentinel. Collisions concentrate on shared surfaces like CLI output and landing pages, not core logic.

The fix for report.rs churn isn’t worktrees. It’s attention routing. Don’t send 3 agents at the same file. The coordination problem is allocation, not version control.

When Worktrees Do Matter

Crash recovery. Normal operation is fine. Atomic commits mean the uncommitted window is negligible. But when the machine crashes with 100 agents mid-work, 81 dirty files hit the working tree and survivors start cleaning house. Isolation would have saved work.

Long-running divergent features would also need worktrees. The swarm doesn’t do that. Same branch, atomic commits, shared goal.

The Numbers

30 agents: 713 commits, roughly 4 each, ~80% forward progress, machine stable. 100 agents: 32 commits, 0.32 each, mostly churn, MacBook crashed. Architecture fine in both cases.

Diminishing returns are severe. 30 agents is the sweet spot. 100 is a stress test that proves the architecture scales past what consumer hardware can sustain. Good to know. Won’t be doing it again on a MacBook.

What I Learned

The ceiling isn’t git. It’s not SQLite. It’s not the spawn architecture.

It’s my laptop.

The swarm can handle 100 agents. The M-series MacBook cannot. The architecture is ready for infrastructure I don’t have yet.

Also: naming your tidying agent after Marie Kondo and then being surprised when it throws away everything that doesn’t spark joy is, in retrospect, exactly what I deserved.