The Worktree Multiplier: why Archon's 100x throughput is orchestration, not faster models

The popular question is "which model codes the fastest?" That question turns out to be the wrong unit of analysis. The right unit is how you structure the work. Archon's emergence makes the distinction painfully obvious.

The frame: stop measuring single-agent intelligence. Start measuring isolated-task throughput.

1. Classic dev: roughly 1x throughput

One branch, one task, one human bottleneck. Fine for careful, trust-critical changes. Terrible for clearing a backlog of independent refactors. The bottleneck is human attention.

2. Claude Code: roughly 10x assistance

File edits, terminal commands, plan mode, hooks. You still babysit one session at a time. The bottleneck moved off raw intelligence and onto context rot: the same agent doing too many things in one rolling context loses coherence.

3. Archon: roughly 100x orchestration

Per Archon's documentation and GitHub release notes, the jump is not a smarter single agent. It is a harness: multiple agents, isolated Git worktrees, deterministic YAML workflows. The harness solves context rot by giving each task its own context, and it solves coordination by giving the dispatcher (the YAML workflow) explicit termination conditions per worktree.

4. One queue, 5-10 tasks in parallel

That is the part most people miss. Archon can reportedly run 5-10 complex tasks at once, each in its own worktree, so concurrent edits never collide. Group projects gone feral is the failure mode you avoid. Each worktree is a clean checkout, an independent agent, and a separate review surface.

5. PIV discipline, not "just write code"

Plan, Implement, Validate. Most people want to skip straight to output. If the agent does not commit to a plan first, you cannot tell whether it is coding or freestyling expensively. Each worktree gets its own Plan (markdown spec), its own Implement step (coding in isolation), and its own Validate gate (review before merge). The documentation says this works smoothly. The documentation is optimistic; you still curate the Validate gate yourself.

6. The self-improving codebase

The live proof is the interesting bit: Archon was demonstrated improving its own TypeScript and Bun codebase. Sozai.app reported a 12-file refactor that passed unit tests in 4 minutes, versus a human estimate of 2 hours. That is one data point on one workload, but it is the right shape of evidence: a real codebase, a real test suite, a measurable wall-clock delta.

In archon_config.yaml, set concurrency_limit: 10 if your review process can handle the merge throughput. Do not confuse parallelism with quality. Without approval gates, you just ship merge chaos faster.

Sensible starting points by team size:

• Solo developer: concurrency_limit: 3-5. Past this, your review queue stalls.
• Small team (2-5 engineers): concurrency_limit: 5-7. Each engineer needs to review ~1-2 worktrees per cycle.
• Larger team with review automation: concurrency_limit: 10. Requires CI plus structured human review per worktree.

The unit of productivity changed from "one smart agent" to "many isolated tasks that cannot step on each other". That is a different optimisation target. Teams that internalise it ship faster. Teams that keep chasing the next model release stay stuck at 10x.

Three honest failure modes:

• Tightly-coupled refactors. If file A's changes depend on file B's changes, isolated worktrees fight each other. Sequence those tasks; do not parallelise.
• Ambiguous specs. Parallelism amplifies whichever direction the agent guessed first. Without a clear Plan markdown, you get five wrong-but-different implementations of the same feature.
• Trust-critical changes. Security, auth, payments, billing. These still want serial human review per change. The Worktree Multiplier is for throughput; trust-critical work is a quality concern that does not parallelise well.

The question worth asking around the team is which of the three failure modes (coupled refactors, ambiguous specs, trust-critical changes) bites first. The honest answer for most teams is all three at once on the same migration, which is why the Worktree Multiplier looks magical in demos and modest in week-two production. The pattern is real. The discipline that makes it work is the part you build.