10x Coding with Parallel AI Agents: Zerg, Toad, and the Future of Development

AI coding assistants like Claude Code are transformative. But there’s a problem: they’re sequential. While you wait for one task to complete, you’re not making progress on the next three. What if you could run multiple AI agents in parallel, each working on a different piece of your project?

That’s exactly what I built. Here’s how Zerg, Toad, and toad-history work together to make development 2-3x faster in wall-clock time - and subjectively feels like 10x.

The Problem: Sequential AI is Slow

When using Claude Code or similar tools, the workflow looks like this:

1. Ask the agent to build the user model
2. Wait 3 minutes
3. Ask it to build the API handlers
4. Wait 4 minutes
5. Ask it to write tests
6. Wait 5 minutes

Total: 12 minutes of wall-clock time, but only because you’re doing one thing at a time.

What if the user model, API handlers, and tests could all be built simultaneously by different agents? Now you’re looking at ~5 minutes total (the longest single task), with the same quality output.

The Solution: Parallel Agents with Barriers

The key insight is that software development has natural phases:

• Phase 1: Define data models and interfaces
• Phase 2: Implement business logic (can parallelize across modules)
• Phase 3: Wire everything together
• Phase 4: Test and validate

Agents in Phase 2 need Phase 1 complete. But within Phase 2, multiple agents can work independently. This is where barrier synchronization comes in.

Zerg: The Parallel Agent Orchestrator

Named after StarCraft’s Zerg rush strategy (overwhelm with many units attacking in parallel), Zerg is the orchestration layer. It launches multiple AI coding agents, each in its own tmux window, and coordinates them using barriers.

zerg run ~/prompts/myproject --prefix Z --barrier 3 --barrier 5

This command:

• Reads prompt files from ~/prompts/myproject/
• Launches agents Z1, Z2, Z3 immediately (Phase 1)
• Waits for all three to complete before launching Z4, Z5 (Phase 2)
• Waits again before launching any remaining agents (Phase 3)

Prompt Structure

Each project has a prompt_master file with shared context, plus numbered promptN files for individual agent tasks:

~/prompts/webapi/
├── prompt_master    # Shared: project structure, tech stack, conventions
├── prompt1          # # Database Schema
├── prompt2          # # User Model
├── prompt3          # # Auth Service
├── prompt4          # # User Handlers
├── prompt5          # # API Router
└── prompt6          # # Integration Tests

The first line of each prompt (starting with #) becomes the agent’s name in the TUI.

For more customization (model selection per agent, effort levels, timeouts), add a zerg.yaml file. CLI flags don’t scale when you have a dozen agents with different requirements.

Real-Time Monitoring

$ zerg plan myproject

ZERG RUN: myproject
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 1 (parallel)
   ✅ Z1   Database Schema     2m 34s
   ✅ Z2   User Model          1m 45s
   🔄 Z3   Auth Service        3m 12s  ← active

BARRIER 3 ━━━━━━━━━━━━━━━ waiting: Z3

PHASE 2 (parallel)
   ⏸️ Z4   User Handlers      blocked
   ⏸️ Z5   API Router         blocked

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⏳ 2/6 complete (33%)  🕐 3m 12s elapsed

Robot Mode: Full Autonomy

With --robot mode, agents complete their tasks and mark themselves done automatically. No human intervention needed until the final result:

zerg run ~/prompts/myproject --prefix Z --barrier 3 --robot

This is the sweet spot: parallel execution with automatic progression through phases.

Why This Works: The Agent Client Protocol

The key enabler for all of this is the Agent Client Protocol (ACP) - a standardized way to communicate with AI coding agents regardless of their backend (Claude, Codex, Ollama).

I first discovered ACP through acp.el, an Emacs package for interacting with AI agents. What I loved about ACP: it provides a perfect interception point for logging, observability, and tooling. And crucially, you can use your existing ChatGPT or Claude subscription instead of managing API keys directly.

That’s exactly what Zerg and Toad do - they leverage ACP to treat AI agents as composable building blocks with full visibility into every interaction.

Toad: The Unified AI Terminal

Zerg orchestrates, but what actually runs each agent? That’s Toad - a beautiful terminal UI for AI coding agents built by Will McGugan (creator of Rich and Textual).

Toad wraps AI agents using ACP, providing:

• A unified interface across different AI backends
• Real-time streaming of agent output
• File diff previews before applying changes
• Tool call visibility

When Zerg spawns an agent, it runs:

toad -a claude --prompt @/path/to/combined-prompt.txt

Each agent gets Toad’s full capabilities, just running in its own tmux window.

toad-history: Learning from Your Sessions

The third piece is toad-history (or th for short) - a tool for browsing and analyzing past AI coding sessions.

Toad stores every session in a SQLite database: messages, tool calls, file changes, timing. toad-history provides:

TUI Mode: Browse sessions interactively

th

Web Mode: Serve a web UI with search and filtering

th serve

Remote Mode: Watch sessions happening on another machine in real-time. Run Zerg on a powerful remote machine and monitor all agents from your laptop.

Why History Matters

With thousands of agent sessions logged, I use toad-history primarily for:

1. Observability: See exactly what each agent did, every tool call, every file change
2. Backtesting: When I add new features to my prompts, compare results against past runs
3. Analytics: Aggregate stats on success rates, timing, token usage across all sessions
4. Model comparison: Long-term comparison of Claude vs Codex vs Ollama on similar tasks

Inter-Agent Collaboration: Zerg Notes

When agents work in parallel, they often discover things that later agents need to know. The database schema agent might find that a column name changed. The auth service agent might discover an API quirk. How do they share this knowledge?

Zerg notes provide an append-only, SQLite-backed note system that agents can read and write:

# Agent Z1 discovers something important
zerg note push myproject findings "User table uses UUID, not integer ID"

# Agent Z4 (in a later phase) reads all findings
zerg note get myproject findings

# List all note keys
zerg note list myproject

# Search across all notes
zerg note search myproject "UUID"

Each agent runs with environment variables ZERG_RUN_ID and ZERG_AGENT_ID automatically set, so prompts can instruct agents to save their discoveries:

## Saving Your Findings

After completing your research, save key findings for other agents:
\`\`\`bash
zerg note push $ZERG_RUN_ID auth-quirks "OAuth callback requires trailing slash"
\`\`\`

Before implementing, check what previous agents discovered:
\`\`\`bash
zerg note all $ZERG_RUN_ID
\`\`\`

Notes are stored in ~/.zerg/{run}/notes.db and persist across the entire run. This solves a fundamental coordination problem: agents in Phase 2 can learn from Phase 1’s discoveries without you manually copying information between prompts.

Raw Agent Experience: Tmux Pane History

Sometimes you want to see exactly what an agent is experiencing - not just the structured session data, but the raw terminal output. Since each agent runs in its own tmux window, you can capture its scrollback buffer:

# Peek at the last 50 lines of agent Z3's terminal
tmux capture-pane -t zerg-myproject:Z3 -p | tail -50

# Capture more history (last 500 lines)
tmux capture-pane -t zerg-myproject:Z3 -p -S -500

# Save the full history to a file
tmux capture-pane -t zerg-myproject:Z3 -p -S - > agent-z3-history.txt

This gives you the unfiltered, real-time view of what the agent sees:

• Command output as it streams
• Error messages in context
• The agent’s reasoning as it types
• Test failures with full stack traces

It’s particularly useful for debugging when an agent seems stuck. The toad-history tools show you structured data (tool calls, file changes), but tmux capture shows you the raw experience - exactly what the agent is looking at right now.

For live monitoring, you can also jump directly into the agent’s window:

zerg jump Z3 myproject  # Attach to Z3's tmux window

Putting It Together: A Real Example

Here’s how I improved the web UI for my intake app (a capture system for photos, text, and voice) using this stack:

1. Create the prompts (10 minutes of thinking):

~/prompts/intake-webui/
├── prompt_master    # Go backend, vanilla JS, Tailwind CSS, project structure
├── prompt1          # Captures List UI - card layout, dark theme
├── prompt2          # Dispatch UI - buttons for each destination
├── prompt3          # File Previews - thumbnails, zoom viewer, OCR display
└── prompt4          # Integration and Polish - testing, error handling

2. Launch the swarm with a barrier after agent 3:

zerg run ~/prompts/intake-webui --prefix W --barrier 3 --robot

3. Monitor progress while doing something else:

zerg plan intake-webui

4. Total time: 8 minutes wall-clock for work that would have taken 30+ minutes sequentially.

The agents worked in two phases:

• Phase 1: UI components (W1, W2, W3 in parallel, 2-4 min each)
• Phase 2: Integration (W4 after barrier, 4 min)

The 10x Claim

Is it really 10x? Here’s my rough math:

Sequential AI coding:

• 6 tasks × ~15 min average = 90 minutes

Parallel with Zerg:

• 3 phases × ~8 min average = 24 minutes
• Plus ~10 min prompt writing

Speedup: ~2.5x in wall-clock time

But the real multiplier is cognitive:

• No context switching: You’re not re-explaining the project 6 times
• Consistent conventions: All agents share prompt_master
• Parallel debugging: If Z3 is stuck, Z1 and Z2 keep working
• Review efficiency: You review 6 completed modules instead of 6 sequential iterations

The subjective experience is closer to 10x. You go from “I’ll have this done by end of day” to “I’ll have this done after lunch.”

One tradeoff: running 6 agents in parallel uses roughly 6x the API tokens. If you’re using ACP with your existing Claude or ChatGPT subscription, this doesn’t matter. With direct API access, factor in the cost.

When to Use (and Not Use) This

Use Zerg when:

• Building a new project with clear module boundaries
• The modules can be specified independently upfront
• You have 3+ distinct pieces of work

Don’t use Zerg when:

• The work is inherently sequential (each step depends on the last)
• You’re exploring or prototyping (not ready for parallel execution)
• The project is so small that orchestration overhead exceeds the gains

Step-by-Step Setup

Here’s exactly how to set up this system from scratch.

Prerequisites

• Python 3.11+ and uv (for toad)
• Go 1.21+ (for zerg)
• tmux (zerg uses it for agent windows)
• Claude API key or Codex CLI configured

1. Install Toad (My Fork)

I maintain a fork of Toad with additional features for parallel orchestration. The fork is heavily modified - I’m still figuring out which features are worth proposing upstream to Will McGugan.

# Clone my fork
git clone https://github.com/charignon/toad.git
cd toad

# Install as a uv tool
uv tool install .

# Verify installation
toad about

To use with Claude:

# Test it works
toad run -a claude "Say hello"

To use with Codex (OpenAI):

toad run -a codex "Say hello"

2. Install Zerg

# Clone zerg
git clone https://github.com/charignon/zerg.git
cd zerg

# Build and install
go build -o ~/bin/zerg .

# Verify installation
zerg --help

3. Create Your First Prompt Directory

mkdir -p ~/prompts/hello-world

Create prompt_master:

cat > ~/prompts/hello-world/prompt_master << 'EOF'
# Hello World Project

You are building a simple Python project in ~/hello-world-output/

## Rules
- Create clean, minimal code
- Add a docstring to each function
EOF

Create prompt1:

cat > ~/prompts/hello-world/prompt1 << 'EOF'
# Greeter Module

Create ~/hello-world-output/greeter.py with a function greet(name)
that returns "Hello, {name}!"
EOF

Create prompt2:

cat > ~/prompts/hello-world/prompt2 << 'EOF'
# Farewell Module

Create ~/hello-world-output/farewell.py with a function goodbye(name)
that returns "Goodbye, {name}!"
EOF

4. Run Zerg

# Dry run first (see what would happen)
zerg run ~/prompts/hello-world --prefix H --dry-run

# Actually run it with robot mode (auto-complete)
zerg run ~/prompts/hello-world --prefix H --robot

5. Monitor Progress

# Check status
zerg plan hello-world

# Interactive TUI
zerg tui hello-world

# Jump to a specific agent
zerg jump H1 hello-world

# Mark success when done
zerg success hello-world

6. Peek at Agent Output

Since agents run in tmux windows, you can peek at their output without interrupting:

# Peek at what agent P1 is doing
tmux capture-pane -t zerg-<run-id>:P1 -p | tail -30

# Example for a run called "myproject" with agent Z1
tmux capture-pane -t zerg-myproject:Z1 -p | tail -50

This is useful for monitoring progress without jumping into the agent’s window.

Key Commands Reference

If an agent gets stuck, use zerg jump to see what happened, then either zerg done to skip it or zerg retry to try again.

About My Toad Fork

My fork of Toad has diverged significantly from upstream. The main themes:

• Headless/robot mode: Auto-approval of all actions, auto-exit when complete - essential for unattended parallel runs
• Performance: Optimizations for running many agents simultaneously
• Model configuration: Easy switching between models and effort levels
• SQLite logging: Every interaction logged for later analysis
• Session browser: UIs to inspect and browse thousands of logged conversations

I may contribute some of these features upstream. I don’t encourage others to use my fork - I’m not sure how much time I’ll have to maintain it.

If you want stability, use upstream Toad and manually mark agents done.

Conclusion

Parallel AI agents aren’t science fiction - they’re a practical tool I use daily. The combination of Zerg for orchestration, Toad for execution, and toad-history for analysis creates a workflow that feels genuinely different from sequential AI coding.

The 10x number is real when you account for the full picture: less waiting, less context-switching, more consistent output, and the ability to tackle larger projects without losing your mind.

The future of AI-assisted development isn’t just smarter agents - it’s smarter orchestration of many agents working together.