Real numbers from stress-testing Tensorlake’s snapshot-and-fork on a free account: the 5× setup win, an isolation proof, and the rough edges nobody puts in the launch post.
Last month I ranked eight AI agent sandboxes and made an argument that annoyed some people: cold-start benchmarks measure a cost you pay once, while real agents live or die on statefulness. Several readers asked a fair question — okay, but did you actually run the stateful workflows, or just read the docs?
Fair. So this time I put money (well, credits) where my mouth is. I signed up for a free Tensorlake account, built a real LLM agent, provisioned its environment once, snapshotted it, and forked it into 12 workers — each solving a different bug-fixing task with a live DeepSeek call inside the sandbox. Every number below comes from timestamped runs on July 28, logged to JSON, on the smallest machine they offer: 1 vCPU, 1 GB RAM.
No staging accounts, no pre-warmed anything, no numbers from a vendor deck.
Here’s the workload pattern that motivated this test. If you’re doing batch evaluation, RL rollouts, parallel code-fixing, or any flavor of “run my agent N times against N inputs,” your loop probably looks like this:
Steps 1–3 are pure tax. And the tax scales linearly with N, because every worker rebuilds an identical world from scratch.
The snapshot-and-fork pitch is: pay the setup cost once, checkpoint the fully-loaded environment, then stamp out clones that wake up with everything already in place — dependencies installed, files on disk, caches warm. The question is whether that actually works, how fast it is, and what breaks.
The agent is deliberately small but real: it reads a buggy Python file, asks DeepSeek to fix it, writes the fix, and proves the fix by executing the file’s own assertions. Pass or fail, no vibes. Five different buggy tasks (off-by-one binary search, mutable default argument, dict-mutation-during-iteration — the classics).
The full experiment scripts run from my laptop with the Python SDK:
pip install tensorlakeexport TENSORLAKE_API_KEY=... # from cloud.tensorlake.ai
First impression worth reporting: the very first sandbox I ever created — cold, free tier, default image —
from tensorlake.sandbox import Sandbox
sb = Sandbox.create() # returned in 1.68ssb.run("python3", ["-c", "print('hello from tensorlake')"])# first command output at 2.9s totalsb.terminate()
A live Ubuntu 24.04 microVM with Python 3.12, git, node, and curl, answering commands in under three seconds from create(). That matched the marketing better than I expected.
First, the “rebuild the world every time” path. Cold-create a sandbox, install the agent’s dependencies (openai, numpy, requests — a modest, realistic set), upload the agent, run one task, destroy. Three runs:
Two things to notice. The median setup tax is 12.3 seconds per worker before the agent does anything useful. And look at the pip line: it swung from 8.4s to 11.8s across three otherwise identical runs — a 40% spread. PyPI, resolver moods, network weather. Multiply that noise by N workers and your fleet’s spin-up time becomes both slow and unpredictable.
Now the pattern under test. Provision one parent sandbox properly — dependencies, agent code, a scratch “memory” file, and a warm-up run so Python’s import caches are hot:
parent = Sandbox.create() # 1.77sparent.run("pip3", ["install", "openai", "numpy", "requests"]) # 10.06sparent.write_file("/tmp/work/agent.py", AGENT_CODE)parent.write_file("/tmp/work/memory.txt", b"parent-scratch: cache warm...")parent.run("python3", ["-c", "import openai, numpy, requests"]) # warm importssnap = parent.checkpoint() # 1.78sparent.terminate()
Total one-time cost: 14.0s of provisioning + 1.78s to checkpoint. The checkpoint captures the full disk state — filesystem, installed packages, caches.
Then the forks. Each worker is just a create call pointed at the snapshot:
worker = Sandbox.create(snapshot_id=snap.id)
I forked 12 workers, and each one: (a) verified it could import all three packages instantly, (b) read the parent’s memory file, (c) received a different buggy task, and (d) ran the real DeepSeek agent against it. The distribution across all 12 forks:
Read that min–max line again. The entire spread across 12 forks was 0.3 seconds. The cold path’s pip step alone had a 3.4-second spread across just 3 runs. Forking didn’t just make workers faster to ready — it made them boringly deterministic, which matters more than the average when you’re orchestrating a fleet.
I got an accidental second proof of this. When I re-ran the whole experiment later the same day to verify my numbers, the parent’s pip install took 22.0 seconds — more than double the original 10.1s, same three packages, same machine size, nothing changed but the weather. The forks from that slower parent? Median create of 2.33s. The one step you can't make deterministic is exactly the step forking lets you stop repeating.
The bottom line per worker: ~12.3s of setup collapsed to ~2.4s — a 5× reduction — and the 5× is the free-tier floor, not the ceiling, because the fork time doesn’t grow when your dependency list does. Fork a 5 GB environment or a 50 MB one; the clone doesn’t re-run pip either way.
For my 12-worker fleet, the arithmetic:
And that 45s is with forks running sequentially (more on why in a moment). With concurrency, the fork path approaches ~18 seconds total for the whole fleet, while the cold path stays wherever your parallelism budget puts it — with every worker independently rolling the pip-install dice.
Speed is half the story. The other half is whether forks are genuinely independent universes, or whether they share mutable state in some way that will eventually ruin your week.
So I tried to break it. Fork A got destructive:
a = Sandbox.create(snapshot_id=snap.id)a.run("bash", ["-c", "rm -rf /tmp/work"]) # wipe everything
Then I created fork B from the same snapshot, after A’s rampage, and read the state file A had just deleted:
fork_b_sees: "generation=0 from parent"isolated: true
Fork B woke up in a pristine copy of the parent’s world, untouched. This is the property that makes the pattern safe for the scary use cases — running untrusted LLM-generated code, adversarial evals, RL rollouts where a policy might rm -rf its own environment. One worker going feral costs you one worker.
1. The free tier is tighter than the pricing page said. When I ran these tests, the pricing page advertised 2 concurrent sandboxes on the free plan. My fresh account got 1:
API error (status 400): 1 sandboxes are running and the project has reached its quota. Contact us in the Tensorlake Slack channel if you need more quota.
That’s why my 12 forks ran sequentially. The fork latency numbers are unaffected — each fork was measured identically — but if you want the cinematic “12 workers alive simultaneously” experience, you’ll be asking for quota in their Slack on day one. To their credit, the error message tells you exactly where to go, and the whole experiment still fit comfortably in free prepaid credits (my grand total for everything in this article: about two cents). Update: when I flagged the 2-vs-1 mismatch, Tensorlake confirmed the free-tier limit is 1 concurrent sandbox and corrected the pricing page the same day.
**2. **write_file 500s on root-level paths — but it’s the default user, not the file API. My first attempt wrote the agent to /work/agent.py after a mkdir -p /work. The file API returned a raw 500:
{"error":"Failed to create parent directories for: /work/agent.py","code":"INTERNAL_ERROR"}
Writing under /tmp/work instead worked perfectly. It turns out this is expected behavior rather than a file-API bug: sandbox processes run as a non-root default user, which can’t create directories at the filesystem root. Tensorlake has since added docs covering the default user and working directory (docs.tensorlake.ai/sandboxes/tensorlake-images). Still, a 4xx with a hint would beat a raw 500.
3. Snapshots bill while they exist. Storage is cheap ($0.07/GB-month), but it accrues while you sleep. If you’re experimenting, Sandbox.delete_snapshot(snap_id) should be in your finally block. Mine was — my account shows zero stored snapshots and zero running sandboxes right now.
None of these are dealbreakers. All three are the kind of thing you only learn by actually running the product, which was rather the point of this exercise.
Reach for snapshot-and-fork when:
Skip it when:
My last piece argued that statefulness beats raw boot speed for real agent workloads. Having now actually built on it: Tensorlake’s snapshot-and-fork delivers the specific thing it promises. Setup tax paid once, clones ready in a flat 2.4 seconds regardless of what’s inside them, genuine isolation proven by an attempted sabotage, and a 12-for-12 pass rate from a real LLM agent running real tasks inside the forks.
The friction I hit was quota-and-polish friction, not architecture friction. The core primitive — checkpoint a fully-loaded machine, stamp out identical independent copies of it in constant time — worked every single time I invoked it, with a variance so low I re-checked my logging code.
If you’re spinning up N identical agent environments a day and paying the setup tax N times, you’re doing linear work for a constant-time problem. That’s the whole review.
*Every number in this piece comes from logged runs on a free-tier account (1 vCPU / 1 GB, Ubuntu 24.04, Python SDK) on July 28, 2026. The experiment scripts — baseline, fork fan-out, and isolation test — total ~200 lines of Python; the agent inside the sandboxes calls DeepSeek’s *deepseek-chat via the OpenAI-compatible API. Total cost to reproduce everything: under $0.05.
I Forked One AI Agent Into 12 Workers — and Every Clone Woke Up Already Knowing Everything was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.