Git is a bad metaphor for most infrastructure. Images are not commits. Containers are not branches. The metaphor holds for isolated machines when you can warm one guest, then fork its current state as copy-on-write children.
That is the core loop in Zeish: prepare once, clone many agent runs. This guide explains what is actually copied, why clones are cheap, and how to use the public API without rebuilding the environment on every eval.
The cost you are trying to delete
A naive agent eval does this every time: pull an OCI image, boot a machine, install language toolchains, warm model caches, load fixtures, then run the prompt. Most of that work is identical across trials. The only thing that should change is the prompt, the tool policy, or the patch under test.
If boot-from-image takes tens of seconds, you either serialize evals or overpay for parallel ones. Zeish forks a warmed guest instead of rebuilding the environment for every run.
Snapshot is a named checkpoint
A snapshot captures a running machine: guest memory, virtual disks, and device state. After you have installed packages and loaded data, you snapshot. That checkpoint is a named record of the sandbox at that moment.
The public API can create, list, and delete snapshots on a sandbox. It does not take a snapshot ID as a clone source. Clone always forks the sandbox's current runtime. Keep the baseline sandbox around (paused if you want) when you need to fan out again. See sandboxes and the SDK reference.
Clone is the branch
Clone forks a sandbox from a running parent. The public route is POST /public/sandboxes/:sandboxId/clone with an optional name. Parent pages stay shared. Each fork pays only for the blocks it writes. That is the git part: cheap branches, shared history, isolated working trees.
A typical eval farm:
- Create a baseline sandbox from a template.
- Install the repo, dependencies, and test data.
- Optionally snapshot the baseline so you have a named checkpoint.
- Clone N sandboxes from the baseline sandbox.
- Run one trial in each clone.
- Destroy the clones. Keep the baseline for the next batch.
Failures do not contaminate siblings. A clone that rm -rfs the workspace is a discarded branch, not a poisoned image cache.
Copy-on-write all the way down
The VMM and the storage path underneath it make this practical. Disks are snapshotted as immutable parents plus overlay writes. Memory restore is a boot from checkpoint, not a BIOS walk. The control plane records lineage from parent sandbox to clone. Which hypervisor produced the guest is not the API.
This is different from “start another container from the same image tag.” An image tag is a filesystem recipe. A clone is a live machine. Agents care about the live machine: warmed JITs, listening daemons, mounted datasets, logged-in CLIs.
Where this beats Kubernetes scale-out
You can scale pods. You cannot cheaply fork a warmed pod with its RAM intact. ReplicaSets start new processes. Zeish clones start from a running parent. That is why agent evals, SWE benches, and parallel prompt experiments map onto machine clones instead of onto horizontally scaled containers.
If you are comparing isolation models rather than clone models, read why containers aren't enough and Zeish vs E2B vs Daytona vs box.
API-shaped, not cluster-shaped
Cloning is a single call on the public API, the CLI (zeishctl sandboxes clone), the TypeScript session client, and MCP. You do not write a CRD to fan out five evals. Warm a baseline, then clone. Lifecycle stays asynchronous: create or clone, wait for running, request data-plane access, work, destroy.
Start with getting started, then the clone and snapshot operations in the API reference. Estimate cost for fan-out on the pricing calculator.