Sandbox lifecycle
Five verbs cover the whole life of a sandbox. Every one is a single API call, idempotent, and billed by the second of allocated vCPU and memory. Here they are in order.
spawn boxA fresh microVM from the warm pool.
Restored from a pre-booted snapshot rather than cold-booting a kernel, which is what keeps a create under 120ms end to end. Billing starts on the allocation you asked for, not on what the guest happens to use.
spawn fork <id>Copy-on-write clone of a running box.
The child shares the parent’s pages until it writes, so N branches of the same state cost far less than N boxes. This is the primitive behind exploring several agent trajectories from one prepared environment.
spawn pause <id>Freeze the VM, stop the CPU clock.
Memory stays resident so resuming is near-instant, and the ledger switches to the cheaper paused rate. The right move for a sandbox waiting on a human, not a teardown.
spawn resume <id>Back to running, from memory.
The process tree, open files and network state are exactly where they were left. Nothing inside the guest has to know it was paused.
spawn rm <id>Hard teardown, resources released immediately.
The tap device, network namespace, jailer chroot and memory are all reclaimed, and billing stops at the same instant. Idempotent, so a retry after a timeout is safe.