Skip to main content
Fork one golden VM into N parallel coding agents. Each agent gets an isolated environment in seconds; together they build something that would take you half an hour alone.

What you’ll build

  • A multiplayer snake game with server, client, and landing page — built by three agents in parallel
  • A reusable golden VM commit you can fork into any future swarm
  • Time: ~25 minutes end-to-end (agent wall time is ~60 seconds)

Prerequisites

  • Vers CLI installed and authenticated
  • An API key for your LLM provider (Anthropic, OpenAI, etc.)
  • Basic familiarity with SSH and REST APIs

The idea

Coding agents are serial — one agent writes one file at a time. A full-stack app with server, client, and landing page takes 10–15 minutes to one agent. But the components are independent. If three agents build them simultaneously, it takes ~60 seconds. The bottleneck isn’t the LLM — it’s the environment. Each agent needs an isolated filesystem, and provisioning a fresh VM from scratch takes minutes. Vers solves that with branching: snapshot a fully provisioned VM once, fork it per agent in 258µs. Every branch is a copy-on-write environment that looks identical at branch time and diverges only on write.

Step 1: Create the Golden Image

The golden image is a VM with your agent runtime and tools pre-installed. You create it once.

Initialize and Launch

Edit vers.toml for enough resources:

Install Your Agent Runtime

Inside the VM, install whatever agent framework you use:

Snapshot It

Save the returned commit ID. This is your golden image — every agent VM branches from it.
The VM is paused after commit. Run vers resume if you want to keep using it, or leave it paused to save resources.

Step 2: Branch Worker VMs

Create one VM per agent by restoring from the golden image:
Each VM boots with the exact state from the golden image — all tools installed, workspace ready. This takes seconds, not minutes.
You should see three running VMs.

Step 3: Write the Spec

Before tasking agents, write a spec that defines the contract between components. This is the only information workers share — they can’t read each other’s filesystems. Create a SPEC.md locally:

Step 4: Task Each Agent

Copy the spec to each worker and start the agent. The exact command depends on your agent framework:

Using the Vers CLI

Start agents on each VM. Open three terminals: Terminal 1 — Server worker:
Terminal 2 — Client worker:
Terminal 3 — Landing worker:
All three agents build simultaneously in isolated environments.

Using the API

For programmatic control, use the Vers API directly:

Step 5: Collect and Assemble

Once agents finish, pull files from each worker VM:

Fix Integration Mismatches

Workers will drift from the spec. Common issues:
  • Server sends segments, client reads snake
  • CSS uses .card, HTML uses .landing-card
  • Server sends [x, y] arrays, client expects {x, y} objects
Review the files, fix mismatches, and copy the assembled project to one VM:

Verify

If you see HTML, the server is running.

Step 6: Serve It

Your app is accessible at:
TLS is handled by the Vers proxy — your VM serves plain HTTP and browsers see HTTPS. Any port in the routed range (1024–10000) works. The one gotcha: bind dual-stack, not IPv4-only:
See Networking for the full details.

Step 7: Clean Up

Or kill the golden image recursively to remove everything:

The Time Savings

The savings compound with more workers. The golden image cost is paid once — every future swarm branches from it instantly.

Automating with Pi Extensions

If you’re using pi, the pi-v extensions automate the entire workflow above into tool calls:
  • vers_swarm_spawn — branches VMs and starts pi agents in one call
  • vers_swarm_task — sends prompts to agents
  • vers_swarm_wait — blocks until all agents finish
  • vers_swarm_teardown — cleans up all VMs
See the Pi Extensions tutorial for how to build Vers integrations into any agent framework.

The pattern

Provision once, branch per task. The cost you pay to install tooling and reach a useful state is fixed — you pay it during vers commit. Every agent after that starts from the same golden snapshot in microseconds. This pattern generalizes beyond coding agents to any workload where:
  • Setup is expensive (installing a runtime, seeding a database, booting an application)
  • Tasks are independent (each agent/worker doesn’t need to read the others’ state)
  • You want many of them (N simultaneous workers instead of N sequential ones)
Keep the golden commit ID in your toolchain. Every future swarm branches from it.

What’s next

Build a pi extension

Wire Vers into your agent framework so swarms spawn with a single tool call.

vers branch

Every flag on the branch primitive.

API reference

Orchestrate swarms programmatically from your own code.

Architecture

How copy-on-write and content-addressable commits actually work.