Running 10+ AI Coding Agents in Parallel

Updated July 2026 — how to scale from one Claude Code session to a full parallel AI engineering team

You can run 10, 20, even 50 parallel Claude Code, Codex, or Gemini CLI agents from a single amux dashboard — and manage the whole fleet from your phone. The practical output: tasks that would take one agent a week ship in a day, overnight, while you sleep. This guide covers everything from machine requirements to fleet organization, atomic task distribution, git conflict prevention, and self-healing overnight operation.

Quick answer: amux runs each agent as an isolated tmux session. The dashboard aggregates all sessions into one view. Agents pull tasks from a shared kanban board using atomic claims — no duplicated work. The self-healing watchdog auto-restarts crashed sessions and auto-compacts context-overflowed ones. Result: a fleet that runs unattended overnight.

What does "running 10+ agents in parallel" actually mean?

Each agent is a separate Claude Code (or Codex / Gemini CLI) process running in its own tmux window. They're independent: each has its own context, its own task, its own branch. amux layers a control plane on top:

That's the foundation of an AI engineering team. Not one agent iterating; dozens of agents shipping in parallel, managed from one place.

Machine requirements for 10–50 agents

The good news: AI coding agents are CPU-idle (they spend most of their time waiting on API responses). The bottleneck is RAM.

Fleet size RAM needed CPU Typical host
1–5 agents 4 GB free 2 cores Laptop, small VM
5–15 agents 8 GB free 4 cores MacBook Pro, e2-standard-4
15–30 agents 16 GB free 8 cores Mac Studio, e2-standard-8
30–50+ agents 32–64 GB free 16+ cores High-memory VM, dedicated server

Each Claude Code session uses approximately 200–400 MB RAM. The amux server itself uses under 50 MB. Network is negligible — agents are sending text to an API, not streaming video.

API cost note: 20 agents running full-tilt on Claude Sonnet costs roughly $5–20/hour depending on task complexity. For overnight runs, use FinOps strategies: set per-session token budgets, use cheaper models for review/test tasks, and reserve the flagship model for implementation.

How to organize a fleet of 10+ agents

The right organization strategy depends on your work structure. Three patterns that work well:

Pattern 1: By feature branch (most common)

Each agent owns one feature branch end-to-end. The agent implements, tests, and opens a PR. No merge conflicts because agents never touch the same branch.

Session: feature-auth      → branch: feat/oauth-refresh
Session: feature-payments  → branch: feat/stripe-webhooks
Session: feature-search    → branch: feat/semantic-search
Session: feature-api-v2    → branch: feat/v2-pagination
Session: bug-triage        → branch: fix/various

Pattern 2: By module (monorepo-friendly)

Each agent owns one package or service. They can all work on the same base branch because their file paths don't overlap.

Session: api-agent       → packages/api/**
Session: web-agent       → packages/web/**
Session: mobile-agent    → packages/mobile/**
Session: infra-agent     → infra/**
Session: docs-agent      → docs/**

Pattern 3: By task type (pipeline model)

Specialized agents form a pipeline. Implementers write code; reviewers audit it; testers write tests; documenters write docs. Each role pulls from its own task queue on the board.

Role Count Queue label Model recommendation
Implementer 5–10 implement Claude Sonnet / Codex
Reviewer 2–3 review Claude Opus (thoroughness)
Tester 2–3 test Claude Haiku (fast/cheap)
Documenter 1–2 docs Claude Haiku

Distributing tasks across the fleet: atomic board claims

The biggest coordination problem with multiple agents is duplicated work. Two agents starting the same task is worse than one agent doing it wrong — it wastes tokens, creates merge conflicts, and wastes your time sorting out which output to keep.

amux solves this with atomic task claiming. The kanban board exposes a POST /api/board/:id/claim endpoint. When an agent calls it:

  1. The board atomically checks whether the task is still unclaimed
  2. If unclaimed, it sets the task to doing and records the claiming session
  3. If already claimed, it returns a 409 — and the agent moves to the next task

To use this in your agents' CLAUDE.md:

# CLAUDE.md — add to each agent's project config
## Task workflow
1. Before starting any task, check the board: GET $AMUX_URL/api/board
2. Find a task in status=todo that matches your role
3. Claim it: POST $AMUX_URL/api/board/TASK_ID/claim
   - If 409: skip to the next unclaimed task
   - If 200: this task is yours — complete it
4. When done: PATCH $AMUX_URL/api/board/TASK_ID {"status":"done","desc":"Result: ..."}

With this pattern, you can add 20 tasks to the board and launch 20 agents — each will independently pull and lock exactly one task. The board shows you in real time who has what.

Preventing git conflicts

Agents writing to the same files is the most common failure mode when scaling past 5 agents. Three approaches:

1. Worktree-per-session: Register each agent's session against a separate git worktree pointing to the same repo. Each worktree is an independent working directory — agents can't see each other's uncommitted changes. Only merge at PR time.

git worktree add ../project-feature-auth feat/oauth-refresh
git worktree add ../project-feature-payments feat/stripe-webhooks
# Register with amux:
amux register auth --dir ../project-feature-auth --yolo
amux register payments --dir ../project-feature-payments --yolo

2. Module boundaries: Use your CLAUDE.md to constrain each agent to its module path. Claude Code's allowed_paths setting works too — set it per-session.

3. Frequent small PRs: Instruct agents to open a draft PR immediately when they start and push commits every 30 minutes. Short-lived branches with frequent pushes mean conflicts surface and are resolved early, not at the end of a 4-hour overnight run.

Monitoring 10+ agents from your phone

The amux dashboard is designed to be the single pane of glass for your fleet — and it's built phone-first. You don't need to sit at your computer.

From the iOS app (or the PWA on Android):

The dashboard uses Server-Sent Events to push live updates to every connected client simultaneously — your phone sees the same state as your desktop within ~2 seconds of any change.

Self-healing overnight operation

Running 10+ agents overnight without babysitting requires the fleet to recover from the inevitable failures: context overflow, network blips, API rate limits, agent stuck in a loop.

amux's watchdog handles each case:

Failure mode amux behavior
Context window overflow Auto-compact (triggers /compact), session continues
Process crash Watchdog detects exit, restarts session, replays last message
API rate limit (429) Agent retries with backoff (Claude Code's built-in behavior)
Agent stuck / no output Stale-session detector flags it on the dashboard
amux server crash Server auto-restarts (watches its own mtime + process supervisor)

For a deep dive into overnight unattended operation, see AI coding agents overnight and self-healing configuration.

Token spend management at scale

20 agents generating tokens simultaneously can hit your API budget fast. Three practical controls:

Per-session model selection: Not every agent needs your most expensive model. Assign Claude Opus to complex implementation tasks and Claude Haiku to fast test-writing or documentation. amux's bulk model-switch in the dashboard lets you change the model for multiple sessions at once.

Task-level token budgets: Add a token limit to each task in your CLAUDE.md: "Stop and report after $X tokens if you haven't shipped a working solution." Agents stay accountable to a budget without needing external enforcement.

Context compaction timing: Context compaction resets the running token cost of a session. Triggering it proactively at natural task boundaries (after a PR is opened, before starting a new subtask) keeps sessions lean and cheap.

For detailed cost tracking across a large fleet, see token spend tracking and the AI agent cost calculator.

Step-by-step: scaling from 1 to 10+ agents

  1. Install amux: git clone https://github.com/mixpeek/amux && cd amux && ./install.sh
  2. Register your project: amux register myproject --dir ~/Dev/myproject --yolo
  3. Decompose your work: break the sprint into independent tasks, add them to the board: amux board add "Implement OAuth refresh flow"
  4. Set up worktrees: one git worktree per agent, each on its own branch
  5. Write a shared CLAUDE.md: include the task-claiming workflow, module boundaries, and PR conventions
  6. Launch the fleet: amux start myproject and open the dashboard
  7. Install the mobile app: iOS App Store → amux, or add the PWA to your home screen
  8. Let it run overnight: the watchdog handles failures; check the board in the morning

Run your AI engineering team with amux

Open-source control plane for parallel Claude Code, Codex, and Gemini CLI agents. Single Python file, zero external dependencies, MIT licensed.

git clone https://github.com/mixpeek/amux && cd amux && ./install.sh
amux register myproject --dir ~/Dev/myproject --yolo
amux start myproject
amux serve  # → https://localhost:8822
View on GitHub amux for startup founders Team workflow setup

Related guides