Skip to main content
Agents are nondeterministic: give the same task to three agents and you get three different solutions, some better than others. Instead of hoping one run gets it right, you can run several attempts side by side and keep the best one. This guide does that with sandbox forks. You prepare a base sandbox once, with the project checked out and its tools installed. Then you fork it three times and run an agent in each fork, each with a different hint or model. Each fork is a full, independent copy of the machine, so the agents can install packages and rewrite files without seeing each other’s work. Finally, you score every fork with the same benchmark, keep the winner, and delete the rest.

Prerequisites

Export your Archil API key, a region where sandboxes are available (aws-us-east-1, aws-us-west-2, or aws-eu-west-1), and an AI Gateway key for the model:
Install the dependencies. The TypeScript agents use the AI SDK; the Python agents call the same model through the gateway’s OpenAI-compatible API.

Create the project

The agents’ task is to speed up a slow function without breaking its tests. Create these three files in a local project directory: the function, its tests, and a benchmark that prints the runtime in milliseconds.
project/primes.py
project/test_primes.py
project/bench.py

Prepare the base sandbox

The base sandbox gets the project in /app, installs pytest, and commits everything to git, so you can diff each agent’s changes later. It also records a baseline benchmark. The project lives on the sandbox’s root filesystem rather than on an Archil disk, because the root filesystem is copied into every fork. Once it’s ready, the base is stopped: it waits as a template without using compute, and forks of it boot as running sandboxes.

Fork, race, and keep the winner

The race script forks the base once per approach and runs an agent in each fork at the same time. Every agent gets the same task plus a different hint, two of them run on Claude Sonnet and one on Claude Haiku, and each has a bash tool bound to its own fork. When an agent finishes, the script scores its fork: the tests and benchmark must be untouched (git diff --quiet), the tests must pass, and the score is the benchmark time. The fastest fork wins; the others are stopped and deleted.
The agents’ commands interleave as they work in parallel, and the whole race usually takes well under a minute. Results vary from run to run; in this one, the fork that was allowed to install numpy won:
The winning fork is still running, with the agent’s change applied and anything it installed still in place, so you can keep working in it: run more tests, push the change from it, or hand it to the next agent. The base is untouched, so you can fork it again for the next task without repeating the setup.

Clean up

A sandbox can’t be deleted while forks of it still exist; the API rejects the request with sandbox has dependent forks. Delete the winning fork first, then the base.

Next steps

Coding agent in a sandbox

Give one agent a persistent machine, run its app as a service, and pause it between sessions.

Persistent sandboxes

Lifecycle, services, network access, and forking in detail.

Branches and checkpoints

Fork an Archil disk instead of a whole machine.

Python SDK

Full reference for sandboxes, disks, and exec options.