Guide · Forking and exploration

How do I try several AI agent approaches in parallel?

Updated 2026-10-31

Do the slow setup once, fork the agent's sandbox into one live copy per approach, run each approach in its own copy at the same time, then compare the results and keep the winner. With kosa8, kosa8 fork copies a running microVM into independent copies that resume with memory and processes intact, and kosa8 explore runs one command per copy, reports each exit code and duration, and keeps the fastest one that succeeded.

01Steps

Install kosa8. It runs on an Apple silicon Mac or on x86-64 Linux.
Do the slow part once. Create a sandbox and run the expensive setup inside it. Every copy you make later inherits this work.
Take a checkpoint of the prepared machine, so the parent can be put back to this point whatever happens next. kosa8 keeps the last 10 checkpoints per sandbox.
Run every approach in its own fork. Give one --variant per approach. kosa8 forks the sandbox once per variant and runs each as sh -c VARIANT in a fresh container from --image, all at the same time. A variant can be any shell command, including a script that starts your agent with a different prompt or strategy.
terminal
```
kosa8 explore web --image node:22 \
    --variant "npm test" \
    --variant "npm test -- --experimental-vm-modules" \
    --variant "npm test -- --babel"
forked 3 branches in 6379ms
 
BRANCH                RESULT   TIME     VARIANT
 web-explore-624461   failed   356ms    npm test
*web-explore-624462   ok       371ms    npm test -- --experimental-vm-modules
 web-explore-624463   ok       1360ms   npm test -- --babel
winner: web-explore-624462
```
The output above is the example from the kosa8 documentation. Add the global --json flag to get each branch's name, variant, exit code, output and duration as JSON for a script to compare.
Compare and keep the winner. The starred branch is kept and the others are removed. To look at every branch first, or to keep one that was not the fastest:

Branch names carry a timestamp. If the name given to --keep matches no branch, kosa8 keeps them all and tells you their names.
Fork by hand when each approach is a long agent session. kosa8 fork makes the copies without running anything. Containers that were running in the parent come along in every copy, still running and under the same id, so you can point a separate agent session at each copy and then reach into it with kosa8 sandbox exec.
terminal
```
kosa8 fork web -n 3 --prefix try
forked web into 3 sandboxes in 4497ms
  try1	192.168.127.2
  try2	192.168.127.2
  try3	192.168.127.2
```
Or let the agent fork itself. kosa8 mcp serve exposes kosa8 to any MCP client, including the tools sandbox_fork and sandbox_explore, so an agent can branch its own machine and compare the outcomes. kosa8 mcp tools lists everything it exposes.

02Why fork a running sandbox instead of starting several fresh ones?

Because the expensive part of an environment is the setup: dependencies installed, a server warm, a cache primed. A kosa8 fork resumes from that finished state with its processes intact, so the setup is paid for once instead of once per approach, and every approach starts from exactly the same instant.

That is the difference from copying files. A fork restores the whole machine (memory, running processes and disk) from one snapshot taken of the parent, so a loaded interpreter or a dev server that is already up is present in every branch. In the documentation example, three branches were forked in 6379ms and then ran their tests in 356ms to 1360ms each.

03How does kosa8 explore choose the winner?

The winner is the fastest branch that exited successfully, not the first one to finish. The other branches are removed unless you pass --keep-all, and --keep NAME keeps a branch you choose instead. Each branch has a two-minute time limit by default, which --timeout changes, and explore needs at least two variants.

Losing branches are removed by default because a dozen live machines left behind after every exploration would quietly exhaust the host. If every branch fails, kosa8 explore says so and exits with an error, which makes it usable in a script or CI job.

04Are the forked copies isolated from each other?

Yes. Each fork is its own microVM with its own kernel, restored from the same snapshot of the parent. A change in one copy touches neither the other copies nor the parent, so a failed approach cannot leave files or processes behind in the one you keep.

Comparing agent strategies this way also keeps the comparison fair: every approach sees the same files, the same installed packages and the same network rules, because they all came from one snapshot. If the parent itself goes wrong later, kosa8 rewind web puts it back to the checkpoint from step 3.

05Other options

Git worktrees. git worktree add gives one repository several working directories, each on its own branch, so several coding agents can edit in parallel without touching each other's files. It is lightweight and needs no extra software. Worktrees separate files, not processes: each one installs its own dependencies, and the agents all run on the same host with the same access.
Multiple containers. Start one Docker container per approach from the same image. Baking the setup into the image means it is done once at build time, and containers start quickly. Each container begins from the image rather than from a running state, and containers share the host's kernel.
Hosted sandboxes. Services such as E2B, Daytona and Modal start many sandboxes from an API, which suits fan-out when the work already runs in the cloud. Check each provider's documentation for its snapshot and fork features.

Worktrees fit file-only experiments, containers fit repeatable setups you can build into an image, and a forked microVM fits approaches that need the same warm, running machine plus a stronger boundary around each one.

06Sources

Related guides

Updated 2026-10-31