> ## Documentation Index > Fetch the complete documentation index at: https://docs.vers.sh/llms.txt > Use this file to discover all available pages before exploring further. # Why Vers? > Compute has been single-timeline forever. That was an accident of implementation. Vers is what happens when branching a live machine is cheaper than allocating memory. Every compute primitive you've ever used runs on a single timeline. Boot, execute, terminate. You make a decision, you commit to it, and if it's wrong you start over. That was never an architectural choice. It was an implementation limit. Forking a machine was too slow to be useful as a primitive, so we all built systems that pretend the option doesn't exist. Snapshots as a rare operation. Checkpoints as a batch job. State as a thing you tear down rather than branch. **Vers removes the implementation limit.** Branching a running VM takes 258µs — memory, processes, sockets, and all. Once branching is that cheap, you stop designing around its absence. You start designing around its presence. ## A different primitive Think about what `fork()` did for Unix. Before it, programs had to serialize, write state to disk, and relaunch to do anything that looked like multitasking. After it, forking was something you did in a tight loop, and a whole class of software — shells, web servers, init systems — became natural to build. Vers is that primitive for whole machines. Four calls: | | | | ----------------- | -------------------------------------------------------------- | | `vers run` | Boot a root VM | | `vers branch` | Fork a live VM in 258µs | | `vers commit` | Freeze any state as an immutable, content-addressable snapshot | | `vers run-commit` | Restore any snapshot, anywhere, forever | That's the whole surface. Every workflow in the rest of this doc is composed from those four calls. ## What becomes possible When forking is free, the shape of the software you can build changes: * **Agent swarms.** Fork one golden VM into a thousand, let agents explore in parallel, keep the winners. See [agent swarms](/tutorials/agent-swarms). * **CI preview environments.** Branch a known-good state at HEAD, boot a preview for every PR in microseconds, tear them down on merge. Zero state drift. * **Rollback as a one-liner.** Commit before every risky change. If the change is wrong, `vers run-commit` and you're back — with memory, running processes, and sockets intact. * **Durable long-running LLM tasks.** Checkpoint at every tool call; if something crashes you resume from the last known-good state instead of re-running an expensive chain. * **Stateful end-to-end testing.** Set up a complex state once, branch to exercise every permutation from that state in parallel. None of these are novel ideas. All of them were impractical when branching was measured in seconds. Making branching cheap makes them trivial. ## What you use today, and why Vers is different Most compute platforms are single-timeline by design. They're excellent at what they do. The distinction isn't "better" or "worse" — it's **primitive vs. derived**. Vers is the primitive; single-timeline tools give you fragments of branching by rebuilding state from scratch. ### Sandbox platforms (E2B, Modal, Daytona) Sandbox platforms boot a fresh VM, run something, throw it away. They're great for stateless isolation — function execution, tool use, ephemeral evaluation. What they can't do is **fork a running state tree**. | | **Vers** | **Ephemeral sandboxes** | | ----------------------------------- | ----------------------------------- | ------------------------ | | Primitive | branchable live VM | single-shot sandbox | | Fork a running process tree | `vers branch` (258µs) | re-run `init` (seconds+) | | State after shutdown | committed + restorable | gone | | Rollback after a change | `vers run-commit ` | re-seed from scratch | | Parallel exploration from one state | N branches of the same live machine | N independent setups | | Memory + sockets carry forward | yes | no | If your workload is "one-shot sandbox," a sandbox is perfect. If any part of it wants to *keep the state and branch from it*, that's a capability gap sandboxes can't close with more speed or more features — it's a primitive they don't have. ### Running a hypervisor yourself You can absolutely run your own microVM hypervisor. The hypervisors are great — they're the thing Vers runs on. What they don't give you is a tree. | | **Vers** | **Raw hypervisor** | | --------------------------- | -------- | ------------------ | | Microsecond branch | yes | you build it | | Content-addressable commits | yes | you build it | | VM tree / parent tracking | yes | you build it | | REST + CLI + SDK | yes | you build it | | Orgs, projects, API keys | yes | you build it | | Managed node pool | yes | you run it | Vers isn't trying to replace the hypervisor — it *is* a hypervisor-backed platform. What it adds is the one primitive the hypervisor doesn't ship with: a branching, committing, restorable tree of live machines. ### Container orchestration (Docker, Kubernetes, ECS, Nomad) Schedulers are about spreading stateless load across many machines. Vers is about branching state across a tree. These compose cleanly: a Vers VM is a stateful worker a scheduler can run, and a scheduler's preview-environment system can be backed by `vers branch` for instant, stateful previews. Put differently: containers were the right answer for the problem "how do we pack stateless services densely." Vers is an answer to the problem "how do we make state a first-class, branchable value." Both are true. The two primitives aren't rivals — they're different axes of the same system. ## Sub-millisecond is the thing We'll keep coming back to this number because it's the axis everything else rotates around: | | | | ------------------- | ---------- | | **Branch p50** | `258.3 µs` | | **Branch p99** | `329.2 µs` | | **End-to-end fork** | `< 1 ms` | Platforms built on re-provisioning can approximate branching, but the latency puts it out of the hot path. You don't fork per-request when forking takes 30 seconds; you design around its absence. Vers branching is within an order of magnitude of a memory allocation. At that latency, branching stops being a batch operation and starts being a thing you do in a loop. ## The argument Compute has been single-timeline since we invented it. Every generation of infrastructure — mainframes, VMs, containers, serverless — carries that assumption forward: one state, one path, commit to the branch or start over. That assumption was correct when branching was slow. It isn't anymore. We think the next shape of compute is a tree: live machines you can branch, states you can commit, histories you can walk. Sub-millisecond branching is what makes the shape practical, and the rest of the system — commits, tree semantics, hypervisor-agnostic isolation — is what makes it dependable enough to build on. If that's the world you want to build in, welcome. Your first VM and your first branch — about 10 minutes. How the tree, branching, and commits actually work. Fork one golden VM into parallel agents. Full-stack app in \~60 seconds. Projects, VMs, HEAD, branches, commits.