Sep 3, 2026
In 1971, fork(2) shipped in the first edition of Unix
UNIX Programmer's ManualK. Thompson, D. M. Ritchie. It came from the Berkeley Timesharing System
A User Machine in a Time-Sharing SystemLampson, Lichtenberger, Pirtle, which traced the idea to a 1963 paper by Melvin Conway
A Multiprocessor System DesignMelvin E. Conway. The contract of fork(2) is simple: calling it traps the CPU into kernel mode to duplicate the calling process.
In 2026, in many applications, the units of work are performed by AI agents that require not processes but often the isolation of a virtual machine. Where is the fork(3) for cloud virtual machines?
Saying no to cyclomatic complexity
Most, if not all, sandbox APIs expose creation, snapshotting, templating, and branching as separate concepts. There is nothing inherently wrong with an expansive API. But for a system as reliability-critical as virtual machine infrastructure, we'd prefer to minimize cyclomatic complexity as much as possible. A single fork operation can, perhaps surprisingly, accomplish most of the lifecycle management that would otherwise diverge across separate execution paths.
Bases
Every product or service built on VM infrastructure has a base VM, and every other VM forks it. There are really no exceptions. That base VM may come from an OCI image or a Dockerfile, but regardless, every VM created during an application session is a fork. Hence our interest in exposing forking as the primary entry point to our service.
Checkpoints
Processes have state that spans RAM and disk, for swap, but none of it is durable with respect to the host machine. Durable VMs have state that spans RAM, disk, and durable storage outside the host machine as well. This makes a VM fork a durable checkpoint. The upstream requirement is that a VM fork must work mid-run. The downstream benefit is that a well-written fork implementation lets users build arbitrary checkpointing logic on top of it.
Branches
Lastly, coding agent workloads benefit substantially from test-time scaling, a technique developed by our lab at Stanford. For many workloads, this requires branching, in some cases mid-execution. Forking is a natural primitive for implementing branching logic. Again, this creates an upstream requirement: forking has to provide control over exactly what gets forked.
One last reason we're fans of fork as a basic primitive: it eliminates infrastructure lock-in. Almost any sandbox or VM API anyone has designed can be implemented with fork. ComputeSDK, for example, is a popular unified API for sandboxes, and in our case, the Arker API is a thin shim on top of fork.