Workspace Snapshots, Forking and Cold Start Performance

When a developer opened one cloud workspace at the start of the day and kept it until evening, a two-minute provision was an irrelevance amortized over eight hours. That assumption is what has broken. Environments are now created per pull request, per review, and per agent attempt, and the same two minutes is charged against a task that may itself only take ninety seconds of useful work. Startup cost stops being an operational detail and becomes the thing that decides whether an entire workflow is viable.

It helps to be precise about what a cold start is made of, because each technique here attacks a different part of it. Scheduling and node acquisition come first, and provisioning a new node dominates everything else. Then image pull, a function of layer size and cache locality. Then filesystem setup and volume attachment, then the repository clone, then dependency installation and build or index warm-up, and only then is the process running and initialized. A technique that removes the last four steps but not the first two has a floor it cannot go below.

That last stage is the one people underestimate. Modal, describing its memory snapshot feature, notes that importing a single large Python library, torch, "executes 26,000 syscalls" - work a container redoes on every cold start even though the result is identical every time. Capturing the state after that work and replaying it attacks a genuinely large constant.

Modal's write-up of its memory snapshot feature is the most useful published account of this technique, because it states both the mechanism and the figures. It describes capturing "the entire state of a Linux container right before it was about to accept a request", specifically "the container's filesystem mutations and its entire process tree", with "the notable exception of live network connections and NVIDIA GPU state" (Modal, January 2025).

The figures it publishes are these, and all of them are the vendor measuring its own platform on its own workloads rather than an independent benchmark. Generally, "memory snapshot restore is about 2.5x faster than a standard container startup". For one specific workload, "a Stable Diffusion inference Function that takes around 13 seconds normally restores in only 3.5 seconds". And for the library import mentioned earlier, importing torch "takes normally around 5 seconds to cold start. With snapshot restore it's around 1.05 seconds at p50 and 0.69 seconds at p0".

Two things make these numbers worth engaging with rather than dismissing. They are attached to named workloads rather than to an abstract "cold start", and they include a percentile rather than a single best case. The exclusions are the part to plan around: live network connections and GPU state are not captured, so anything holding an open database connection, a leased credential, or an initialized GPU context has to re-establish it after restore. That reconnection work is real, it happens after the snapshot restores, and it is not inside the quoted number.

Forking generalizes the snapshot from a restore mechanism into a branching one. Instead of restoring a snapshot once, you restore it many times to create workspaces that share every byte of setup and then diverge. That maps exactly onto how agents are used: bring one workspace to the point where the repository is cloned, dependencies are installed and the build cache is warm, then fork it once per candidate approach. The expensive prefix is paid once instead of N times. It is the same economic argument as copy-on-write database branching, applied to the whole machine rather than one datastore.

The correctness problems follow directly from what a snapshot preserves. Every fork inherits the same in-memory state: the same random seeds, the same cached identity, the same open descriptors, the same idea of its own hostname. Anything derived from those is now shared across siblings that believe they are independent. External resources are worse, because a snapshot taken while holding a lease, a lock or a queue subscription produces N processes that all think they hold something exactly one of them can hold.

Agent workloads have an unusual duty cycle. A session spends much of its wall-clock life waiting: for a model response, a build, a test suite, a human review. Under conventional per-instance billing all of that is charged at full rate, which is what makes warm pools and long-lived sessions expensive in a way that traditional service workloads are not.

Some platforms bill the waiting differently, and Cloudflare's model is the clearest published example. Its Workers documentation states that "CPU time measures how long the CPU spends executing your Worker code" and that "waiting on network requests (such as fetch() calls, KV reads, or database queries) does not count toward CPU time". Note the precise term: this is CPU time versus wall time, not a product called "active CPU".

The important asymmetry appears when you move up to containers. Cloudflare's container pricing states that "CPU usage is based on active usage only", but that "memory and disk usage are based on the provisioned resources". A container waiting on a model response stops accruing CPU charges and keeps accruing memory and disk charges for the whole time it is awake. That is a materially better shape than paying for everything, and it is not free idling. Any capacity model that assumes idle costs nothing will under-forecast.