# Run several coding agents in parallel, one VM each

> 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.

Source: https://sandboxer.com/guides/run-coding-agents-in-parallel. Updated 2026-10-24.

**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

```bash
sbx new --type default
sbx ssh sb_k3v9x2mq      # clone the repo, install dependencies, check the tests run
```

Then save it. Re-using a name replaces the old template.

```bash
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

```bash
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
done
```

Each 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

```bash
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.txt
```

Use `--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`:

```bash
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.

```bash
sbx stop $id          # keep it for later, free while stopped
sbx delete $id --yes  # gone for good
```

## Several conversations in one VM

When tasks share one environment, for example a refactor and its tests, run parallel conversations in the same sandbox instead:

```bash
sbx prompt sb_k3v9x2mq --new "Start the billing refactor"
sbx prompt sb_k3v9x2mq --new "Investigate the flaky e2e test"
sbx conversations sb_k3v9x2mq
```

## What 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.