Fork or Restart? Choosing the Right Way to Run Parallel Agent Attempts

Your agent has three plausible fixes for a bug and one shot at being right. You can run them one after another, spin up three fresh environments, or fork the running sandbox it already lives in. Each path costs different amounts of time, money, and state. This guide gives you the decision criteria so the choice is mechanical, not a guess.

Introduction

Running several approaches in parallel is the obvious answer to "which fix is best." The less obvious question is what "parallel" should mean for your infrastructure. A fresh container per attempt throws away everything the agent already figured out. A single sequential run costs wall-clock time and loses the comparison. Forking a running sandbox branches the machine itself: memory, disk, and working state, so every attempt starts from exactly where the agent is now.

CreateOS Sandbox supports all three patterns, because every sandbox is a Firecracker microVM with its own guest kernel, and pause, resume, and fork are built on full memory-plus-disk snapshots. The right choice depends on what state you need to keep, how long the attempts run, and what you do with the losers. This piece walks through the criteria and the if-then rules.

Key Takeaways

State is the deciding factor. If the attempts must start from the agent's current context (installed dependencies, a half-migrated repo, an open browser session), only a fork preserves it. If every attempt is stateless, fresh environments are simpler.
Forking branches a paused sandbox. Pausing writes a snapshot of full guest state and stops compute billing; forking branches that memory and disk state into parallel runs. You keep the winner and discard the rest.
Pause and resume have known costs. Pause takes about 1.4 seconds. Same-host resume comes back in under 0.7 seconds. Budget for that when you compare against a cold start, and check the current figures in the Sandbox docs.
Losers are cheap to throw away. Per-second billing and pause-stops-the-meter mean idle branches do not accumulate cost while you deliberate.
Networking changes the calculus. If parallel attempts need to talk to each other or to shared services, private overlay networks with per-network DNS matter more than raw spin-up speed.

Decision Criteria

1. How much state does each attempt inherit? Everything: fork. Nothing: fresh sandbox per attempt. Partial (a repo checkout but not runtime state): snapshot-restore into fresh sandboxes, if your tooling supports it.

2. Do the attempts need to interact? Rollouts that must share findings mid-run (multi-agent search, voting on candidates) need sandbox-to-sandbox networking. Independent attempts that must not contaminate each other need isolation, which is the default: each fork is its own machine with its own kernel.

3. What does egress look like for each branch? Outbound access is open until you set at least one rule; once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. If your attempts hit different external services, set the allowlist per branch through the egress field at create time, PUT /v1/sandboxes/{id}/egress, the SDK's setEgress, or the CLI's createos sandbox firewall set. Rules apply live, no restart needed.

4. What is the cost shape? Per-second billing with $0 egress means the bill tracks concurrency and duration, not unit price (published rates). Three forks running for five minutes cost what three machines running for five minutes cost, and a paused branch bills nothing. The real cost of the sequential path is wall-clock latency, which per-second billing does not show you.

5. What happens to the losing branches? If you need the losers' logs or traces for evaluation, keep them paused or export state before destroying them. If not, destroy immediately. Traces and usage dashboards are live, so per-attempt history is available either way.

How To Choose

If the attempts are stateless and short, skip forking. Create a fresh sandbox per attempt, run them concurrently, keep the best output. This is the simplest pattern and the easiest to reason about. Start at CreateOS Sandbox with 500 free credits and measure it on your own workload.

If the attempts must start from the agent's current state, pause the sandbox (about 1.4 seconds), fork it N ways, and resume each branch. Every branch resumes the exact machine: same memory, same disk, same running processes. This is the pattern for "the agent is three-quarters through a migration and you want three candidate completions."

If one attempt looks like a winner mid-run, pause the losers instead of killing them. Pause stops the meter, so a paused branch costs nothing while you verify the front-runner. Resume a loser in under 0.7 seconds on the same host if the front-runner fails verification.

If the attempts need to collaborate, attach the branches to a private overlay network. Multi-agent systems find each other by name over private DNS, with no public exposure, and traffic between networks is denied by default.

If the code or data cannot leave your infrastructure, the same fork pattern runs on your own machines. Bring your own compute keeps the API identical; bring your own S3, R2, or MinIO bucket keeps the snapshots in your boundary.

If this runs inside CI, each build or candidate run gets a fresh microVM that is destroyed when it finishes. For Jenkins specifically, the CreateOS Sandbox plugin gives every build its own agent, and the egress allowlist is set on the sandbox itself through the API or CLI, not in the plugin.

Frequently Asked Questions

Does forking copy the whole disk every time? No. Fork branches the paused sandbox's memory and working state from the snapshot. Storage is backed by your own or CreateOS-managed S3-compatible storage, so branches share the base and diverge only on writes.

How fast can I get from "idea" to "three parallel attempts"? Creating a sandbox from a snapshot restores in tens of milliseconds, about 30 ms on an idle host (an idle-host figure, not an SLA, per the docs). Add the roughly 1.4-second pause before forking a live sandbox.

What happens to the forks I do not keep? Destroy them. Billing is per second and stops when the sandbox is paused or destroyed, so losing branches cost only the seconds they actually ran.

Can the branches reach the internet? Outbound access is open until you set at least one egress rule. Once set, everything else is denied, enforced in the host kernel outside the guest, so code inside a branch cannot rewrite or route around it. Inbound is closed by default regardless.

Conclusion

The decision reduces to one question: does the next attempt need the current one's state? If yes, pause and fork, because a fork resumes the exact machine rather than a reconstruction of it. If no, fresh sandboxes per attempt are simpler and just as isolated. Either way, price the pattern in seconds of concurrency, keep the losers paused until the winner is verified, and set egress rules per branch when the attempts touch different services. The Sandbox docs cover the fork and egress APIs, and pricing shows what a parallel batch costs before you run it.

Start free with 500 credits at createos.sh and fork your first running sandbox today.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.