Agent swarms: running many agents in parallel

Why give each agent its own VM?

Separate machines remove the conflicts that appear when agents share one computer. Sandboxer's parallel agents guide compares the common setups:

Worktrees are still a fine choice when agents only edit and test code. Once they run dev servers, databases or Docker, separate VMs let every agent bind the same port and get its own URL. The site covers this trade-off in git worktrees or one VM per agent.

How do you start a swarm from one template?

Set up one sandbox the way every agent needs it, save it as a named snapshot, then create one sandbox per task from that snapshot. Each new sandbox starts with the repo and dependencies already in place.

# once: prepare the repo, then save it as a template
sbx snapshot <sandbox-id> my-repo-ready
sbx stop <sandbox-id>

# then: one sandbox per task
for task in fix-auth add-export flaky-e2e; do
  id=$(sbx new --from my-repo-ready --json | jq -r 'select(.event=="ready") | .id')
  sbx prompt "$id" --provider claude-code "Work on: $task. Commit on a branch named $task."
done

You can mix agents in one swarm. The --provider flag accepts Claude Code, Codex, OpenCode, Pi, Kimi and Mistral Vibe, using your own provider keys. To watch or redirect an agent, use sbx events --follow and sbx steer.

Should you fork or start from a snapshot?

Use a named snapshot for many copies of a fixed starting point, and a fork to copy a sandbox you are working in right now. Both copy the disk with a copy-on-write reflink, so neither waits on a full disk copy. Neither copies memory: each copy boots fresh.

A common fork pattern is best-of-N. You prepare a repo once, fork it once per attempt, run the tests in each fork, and keep the diff with the most passing tests. See forking sandboxes for details.

How many agents can run at once?

Your plan sets how many sandboxes can be active together and how fast you can start them. Stopped sandboxes do not count. These figures come from Sandboxer's pricing page:

Creates, resumes and forks each count as a start. Going over returns a 429 error with a Retry-After header, so a well-behaved orchestrator paces its starts and queues extra tasks.

Can several agents share one sandbox?

Yes. One sandbox can run several agent conversations at the same time, each with its own process and history. This suits related tasks that share one environment, such as a refactor and its tests.

sbx prompt <sandbox-id> --new "Start the billing refactor"
sbx prompt <sandbox-id> --new "Investigate the flaky e2e test"
sbx conversations <sandbox-id>

The number of parallel conversations per sandbox grows with its memory. Beyond that limit, prompts wait in a queue.

What does a swarm cost?

You pay per second for each sandbox while it runs, at its size's hourly rate. A default sandbox (4 vCPU, 8 GB) is $0.036 an hour and small is $0.018. Sandboxer's guide works out that three agents on default for two hours cost about $0.22, plus your model provider's charges on your own key. Stopped sandboxes cost nothing, so stop or delete agents as they finish. More in pricing.