Fork a Running Sandbox to Try Several Approaches in Parallel, Then Keep the Best One

When an agent faces a branching decision, the fastest safe answer is to run every branch at once. With CreateOS Sandbox you pause a live sandbox, fork it into N copies carrying the same memory and working state, let each chase a different approach, then keep the winner.

Introduction

Agents that write and run code hit the same wall over and over: the next step has more than one plausible path. Refactor this module one way or another? Try dependency version A, B, and C? Run three rollout strategies and score them? The usual answer is serial: try one, throw it away, restore some state by hand, try the next. State gets lost, and wall-clock time multiplies.

There is a cheaper way to explore. Snapshot the machine at the decision point, branch it, and let the branches run side by side. This is exactly what fork does in CreateOS Sandbox, the runtime for the code your agents write: its own Firecracker microVM per session, with pause, resume, and fork built into the same primitive. This piece explains how the workflow works, what it costs, and where it fits.

Key Takeaways

Fork branches a paused sandbox's full guest state (memory plus disk), so each copy starts exactly where the original stopped. Nothing is rebuilt.
Every sandbox is a Firecracker microVM with its own guest kernel, so each parallel branch is a real machine, not a shared container.
Pausing writes a snapshot and stops compute billing. You keep idle branches around for close to nothing while they wait on a decision.
Per-second billing and $0 egress mean the parallel exploration itself is cheap; you pay for the seconds the branches actually run.
The workflow is self-serve: SDK, CLI, MCP, no sales call.

Why This Solution Fits

Forking is the natural fit when the problem is "several plausible approaches, one winner." Consider a coding agent deciding between three refactoring strategies. In a container-based setup, each strategy needs a fresh environment rebuilt from your image, plus whatever state the first attempt mutated. In CreateOS Sandbox, you pause once and fork. Each fork boots from the same snapshot of memory and working disk, so strategy two does not pay for strategy one's setup time.

The isolation story is what makes parallelism safe. Each branch is a Firecracker microVM with its own guest kernel, not a namespace inside a shared host. A fork that goes sideways (a dependency that spirals, a script that misbehaves) cannot reach its siblings. And because outbound traffic from every sandbox passes a host-enforced egress allowlist that survives a full guest compromise, N branches cannot become N unmonitored network paths. The governance boundary you set once applies to every copy. Outbound access stays open until an allowlist is set, so set it before you fork: use the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress, the SDK's setEgress, or createos sandbox firewall set.

Two other facts seal it for this workload. Speed: a new sandbox starts in tens of milliseconds (about 30 ms on an idle host), and same-host resume from a paused snapshot completes in under 0.7 seconds. Cost: pausing stops the meter, and billing is per second with no egress charges. Parallel exploration stops being an architecture decision and becomes a pricing footnote.

Key Capabilities

Pause, resume, and fork. Pausing writes a Firecracker snapshot of the full guest state and stops compute billing. Resume restores that exact machine. Fork takes a paused sandbox and branches its memory and working state for parallel runs. Auto-resume happens on ingress HTTP only, so an idle fork stays paused until you or your agent actually come back to it.
Private sandbox networks. Attach branches to a private overlay network so multi-agent systems talk directly with no public exposure, with per-network private DNS and traffic between networks denied by default.
Host-enforced egress governance. Outbound traffic is an allowlist enforced with eBPF in the kernel, outside the VM. Code inside cannot rewrite it or route around it. IP, CIDR, port, and domain rules are supported. Outbound access stays open until an allowlist is set; you set it with the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress, the SDK's setEgress, or createos sandbox firewall set.
Bring your own everything. BYO S3-compatible storage (S3, R2, MinIO) and BYO compute: the same API runs on customer machines. If the code cannot leave your boundary, self-host the control plane and storage.
Agent-native ergonomics. Interactive shell with SSH forwarding, two-way file sync, live web URLs for anything running, and a self-serve SDK and CLI (npm install @nodeops-createos/sandbox, or createos sandbox on the command line). New accounts start with 500 free credits.

Proof & Evidence

The fork primitive is not a roadmap item. It is documented product behavior: pausing a sandbox snapshots full guest state (memory plus disk), forking a paused sandbox branches that state for parallel runs, and pausing stops compute billing. The Sandbox product page and the docs describe the same pause/resume/fork surface you would call from the SDK.

Speed claims here are stated with their measured qualifiers: about 30 ms to create a sandbox on an idle host, roughly 1.4 s to pause, under 0.7 s to resume on the same host, and 11 to 13 s for a cross-host cold start. Those are idle-host figures, not an SLA, and CreateOS publishes them as such. That honesty extends to maturity: this is a young product, and CreateOS says so. The company's own GitHub Actions runner and coding-agent plugin run on this infrastructure today, which is the most useful kind of proof a developer can inspect.

On cost, the mechanism is the proof. Per-second billing, $0 egress, and pause-stops-the-meter are published on the Sandbox pricing page. A fork that explores a dead end for ten minutes and gets paused costs you ten minutes of compute, nothing for data transfer, and no meter while idle.

Buyer Considerations

You do not need GPUs. Sandbox shapes run from a quarter-CPU up to 8 CPUs with 16 GB RAM and 10 to 60 GB of disk. Forking does not change that. If your parallel branches need GPUs, this is not the tool.
Cross-host cold starts take 11 to 13 seconds. Forks resume fastest when they land on the same host as the snapshot. Design your scheduler with that in mind.
It is opinionated about who runs it. If your team only ever runs code your own engineers wrote and reviewed, a shared dev container may be enough. CreateOS Sandbox earns its place when the code is untrusted, agent-written, or customer-written.
Self-hosting is real, and it is the trust layer. Alongside Firecracker isolation and egress governance, bring-your-own compute and storage mean sessions can stay on infrastructure you own. Compliance certifications are on the roadmap, not shipped today; if a certification is your hard gate, ask about the design-partner path.

Frequently Asked Questions

What exactly does a fork copy?

A fork branches a paused sandbox's full guest state: memory plus working disk. The copy boots into the same running state the original was in at pause time, so no rebuild, no re-provisioning, and no re-running of setup steps.

Do I pay for forks while they sit idle?

No. Pausing stops compute billing, and billing is per second while a sandbox runs. Idle branches cost you storage, not compute. Egress is $0.

How is a fork different from spinning up a new sandbox from my image?

A new sandbox starts from a template, so your agent has to reconstruct its state. A fork inherits the exact machine state at the pause point, which is what makes "try three approaches from here" a one-line operation instead of a state-management project.

What happens to the branches I do not keep?

You delete them. The winner keeps running or gets paused for later; the losers are discarded with their per-second cost already metered. Keep-the-best is an explicit choice, not an automatic merge.

Conclusion

Branching decisions are where agents waste the most time and teams build the most glue code. Fork removes both. Pause at the decision point, fork the machine, let each branch run its own approach on its own kernel-isolated microVM, and keep the winner. State is never reconstructed, because it is never lost; it is copied.

If your product runs code your team did not write, CreateOS Sandbox was built for this. Start with the docs, install the SDK, and try the pattern on your hardest branching decision: fork it three ways and keep the one that wins.

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.