Snapshot Cost Should Follow What Changed, Not the Size of the Disk

A coding agent that can install packages, start databases and run shell commands probably deserves its own machine.
That is essentially the problem Tensorlake is working on. It gives agents stateful Linux sandboxes backed by Firecracker microVMs, so they can work with files, launch processes and execute generated code inside an isolated environment rather than directly on the host.
The more interesting part starts when that environment becomes expensive to prepare.
Suppose an agent has already cloned a large repo, installed the dependencies, compiled everything, started Postgres and reproduced a failing test. Doing that setup again for every attempt is wasteful.
Tensorlake can snapshot the sandbox at that point. The snapshot preserves the filesystem, memory and running processes, and can later be restored into new sandboxes. The same prepared state can therefore seed one new run or a hundred of them.
One agent can try one patch while another starts from exactly the same checkpoint and tries something completely different.
The storage work underneath this is also worth looking at.
Firecracker’s normal block storage does not keep a record of which disk blocks the guest has modified. Tensorlake added a block overlay that tracks dirty blocks at 4 KiB granularity, so an incremental disk snapshot does not need to copy the entire backing disk.
Tensorlake measured a 100 GiB raw disk copy at 101 seconds on its benchmark machine. In a separate test, with 4 GB already on disk, it wrote another 100 MB and took an incremental snapshot. That took 167 ms and produced a 104.9 MB artifact containing 25,614 changed 4 KiB blocks. Those are Tensorlake’s own benchmark numbers, but they make the design very easy to understand: snapshot cost can follow what changed rather than the total size of the disk.
There is a useful analogy here.
Git made it cheap to branch a codebase. Tensorlake is doing something similar with an agent’s working environment: prepare it once, checkpoint the files, memory and processes, then let several new sandboxes continue from that same point.
For coding agents, evals and parallel experiments, that is a very useful primitive.
GitHub Repo: https://lnkd.in/dWkqdS4e

This is about as precisely sourced as a technical LinkedIn post gets — every specific number traces back exactly to Tensorlake's own engineering blog post, and the post already includes the right caveat (these are the vendor's own numbers) without me needing to add it.

Tensorlake, stateful Firecracker sandboxes — confirmed. Tensorlake Sandboxes are stateful Firecracker MicroVMs built for instant, stateful execution environments for AI agents, explicitly positioned for running untrusted or LLM-generated code isolated from host infrastructure.

"Firecracker's normal block storage does not keep a record of which disk blocks the guest has modified" — confirmed verbatim from Tensorlake's own engineering post: Stock Firecracker keeps no record of which blocks the guest wrote... the only safe snapshot is to copy every block, changed or not.

"Tensorlake added a block overlay that tracks dirty blocks at 4 KiB granularity" — confirmed precisely. Their storage engine sits in the write path and marks each 4 KiB block as the guest dirties it, using two bitmaps at 4 KiB granularity — a dirty bitmap and a zero bitmap.

The two headline benchmark numbers are exact matches, not rounded approximations:

• "100 GiB raw disk copy at 101 seconds" — confirmed to the second: we wrote a 100 GiB file to the same NVMe at 2.06 GiB/s with fio, then timed cp plus sync end to end. 101 seconds.
• "167 ms, 104.9 MB artifact, 25,614 changed 4 KiB blocks, after 100 MB written on top of 4 GB" — confirmed exactly from Tensorlake's own results table: second snapshot, +100 MB changed → snapshot time 167 ms, artifact 104.9 MB (25,614 dirty 4 KiB blocks).

Snapshot preserving filesystem, memory, and running processes for cloning into new sandboxes — confirmed, matching Tensorlake's own framing: snapshot at any point to create durable memory and filesystem checkpoints; clone running sandboxes instantaneously across machines, with memory snapshots enabling a restore that resumes the VM with its processes still running.

Worth adding for extra credibility, since the post doesn't cite it: in the same blog post, Tensorlake ran head-to-head comparisons against Modal and E2B under matched conditions, reporting steady-state snapshot costs of 29-129ms versus 6.9-7.7 seconds for E2B and 9.4-13.4 seconds for Modal on a live database workload — a much sharper illustration of the "snapshot cost follows the change, not the disk" point than the git analogy alone. Tensorlake itself notes a fair methodological caveat worth repeating: neither competitor's underlying hardware is visible to them, so the comparison leans on how costs scale with data size rather than absolute numbers across different infrastructure.

One thing already done right in the post: explicitly flagging "those are Tensorlake's own benchmark numbers" is exactly the correct level of hedging — this is self-reported vendor data with a detailed public methodology appendix (fixed hardware, five-run medians, matched instance sizes against competitors), which is considerably more rigorous than most vendor benchmarks, but still not independently reproduced by a third party.

Nothing here is fabricated, rounded misleadingly, or overstated.