Run several coding agents in parallel, one VM each
Updated October 24, 2026 .md
Short answer: Give each agent its own cloud VM instead of sharing one checkout. Set up your repo once in a Sandboxer sandbox, save it as a named snapshot, start one sandbox per task from it, and send each a prompt. Every agent gets its own disk, Docker and ports, so they never collide, and you keep the branches that worked.
Why one VM per agent#
| Approach | What goes wrong |
|---|---|
| Several agents in one checkout | They edit the same files and break each other's builds |
| Git worktrees on one machine | Files are separate, but ports, Docker, databases and CPU are shared; your laptop has to stay awake |
| One VM per agent | Nothing shared: own disk, own Docker, own ports; runs while your laptop sleeps |
1. Prepare a template once#
sbx new --type default
sbx ssh sb_k3v9x2mq # clone the repo, install dependencies, check the tests runThen save it. Re-using a name replaces the old template.
sbx snapshot sb_k3v9x2mq my-repo-ready
sbx stop sb_k3v9x2mq # the template doesn't need to keep running (or billing)2. Start 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')
echo "$task $id" >> runs.txt
doneEach new sandbox starts from the template's disk, so the repo and dependencies are already there. Your plan sets how many can run at once: 100 on the $20 plan, and 2 during the trial.
3. Prompt each agent#
while read task id; do
sbx prompt $id --provider claude-code "Work on: $task. Commit on a branch named $task and push it."
done < runs.txtUse --provider codex (or opencode, pi, kimi, mistral) to give some tasks to another agent. Add your provider keys on the dashboard's Agents page first.
Pushing needs Git credentials in the sandbox, for example a repository token passed by your environment or with -e.
Watch or steer any of them, using an id from runs.txt:
id=$(awk '$1=="fix-auth"{print $2}' runs.txt)
sbx events $id --follow
sbx steer $id "Don't touch the database schema"4. Keep what worked#
Check each branch, open pull requests for the good ones, and delete the sandboxes you don't need. Or stop them: a stopped sandbox costs nothing and resumes with the agent's session still in memory.
sbx stop $id # keep it for later, free while stopped
sbx delete $id --yes # gone for goodSeveral conversations in one VM#
When tasks share one environment, for example a refactor and its tests, run parallel conversations in the same sandbox instead:
sbx prompt sb_k3v9x2mq --new "Start the billing refactor"
sbx prompt sb_k3v9x2mq --new "Investigate the flaky e2e test"
sbx conversations sb_k3v9x2mqWhat it costs#
You pay per second for each sandbox while it runs: default (4 vCPU, 8 GB) is $0.036 an hour and small is $0.018. Three agents on default for two hours cost about $0.22, plus your model provider's charges on your own key. Stopped sandboxes are free.
FAQ#
How many agents can I run at once?#
As many as your plan allows to be active together: 100 on the $20 plan, 300 on $100, 1,000 on $500 and 2,000 on $2,000. Starts are also rate-limited per minute, hour and day.
Can different agents use different models?#
Yes. Pick the harness per prompt with --provider and the model with --model. GET /provider-models lists the models each harness accepts.
Do the agents share files?#
No. Each sandbox has its own disk. They only share what they push, such as git branches.
Is a fork faster than starting from a snapshot?#
Both copy the disk with a copy-on-write reflink, so neither waits on a full copy. Use a named snapshot when you start many copies of one prepared state, and a fork to copy a sandbox you're working in right now.
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.