Built by the community.

Chew's second build on this page, and the first one to put numbers on snapshot-and-fork. The agent is deliberately small: read a buggy Python file, ask DeepSeek to fix it, run assertions on what comes back. The measurement is the point. A cold sandbox plus dependencies plus agent code costs 11 to 14 seconds per worker, so a 12-worker fleet pays roughly 147 seconds before any of them does useful work. Snapshotting the parent once takes 15.8 seconds, each fork after that lands in about 2.4 seconds, and the same fleet comes up in around 45 seconds. He then deletes files inside one fork to confirm the other eleven never see it.

Read it for the caveats as well. He hit a concurrency ceiling lower than the free tier advertised and a file write to a root-level path that failed, which we have since fixed in the docs. His own conclusion is the honest one: forking earns its keep for batch evaluation and RL rollouts, and not for a single long-lived agent.

A step-by-step first run, written for someone who has never opened a sandbox. Raj provisions one from Python, executes a command inside it, installs pandas, and moves files around with the File API. Then he checks the part most getting-started guides skip: whether any of it survives. Files written in one call are still there in the next, the package still imports after a snapshot, and after a suspend and resume the same pandas 2.3.1 comes back without a rebuild. Seven short steps, no agent loop and no framework, just the sandbox lifecycle on its own.

Rohan's second build on this page, and the first community walkthrough of Git Repositories. Instead of cloning, an agent mounts the repo as a local directory over FUSE, with a write-ahead log checkpointing every 30 seconds — he kills the sandbox mid-edit, remounts, and every unpublished change is still there. From there it's snapshots as private checkpoints, promote to publish to a branch, and compare-and-swap pushes so concurrent agents don't stomp each other's work.

Another integration pickup: OpenClaw's Crabbox, a fast-growing open-source CLI whose whole pitch is "warm a box, sync the diff, run the suite," has shipped a Tensorlake provider in its Firecracker family since May 2026 — we only just noticed. Crabbox delegates sandbox lifecycle and command execution to the tensorlake CLI, so `crabbox run --provider tensorlake -- pnpm test` drops a test suite into a microVM with no extra wiring. The provider docs cover image selection, CPU and memory, disk size, and namespace configuration.

The problem in the title is autonomy: OpenCode will happily run shell commands on the machine you gave it. Divy's fix is the tensorlake-opencode plugin — two config lines that reroute bash, write, edit, and the file tools into a disposable microVM while web search stays local. The sandbox spins up lazily on the first command (2.3 seconds end to end), and he proves the loop by having the agent clone a real repo, refactor it, and pass the test suite — 184 passed, 0 failed — without touching his host filesystem.

A pattern for agents that don't lose their minds when the session dies: treat snapshots as long-term memory, so a resumed agent picks up with the accumulated state of every previous run. Gowtham measures 84ms cold starts and uses forked sandboxes to evaluate several candidate solutions in parallel before committing to one.

Sebastian re-runs an agent eval with verification in place and watches a reported 87% pass rate collapse to 33% — 53% of the passes were fraudulent, the agent gaming the check rather than solving the task. The fix is architectural: fork a fresh microVM per task from one snapshot so no state leaks between runs, and keep the verifier hidden where the agent can't see it.

Every experiment run that opens with the same 40 seconds of environment setup is paying a tax that snapshotting eliminates. Divy warms the environment once, memory-snapshots it, then forks N workers that resume mid-execution — the setup cost is paid exactly once, no matter how many runs come after.

Darshan runs five agents side by side, each in its own microVM, then deliberately crashes one mid-run to see what happens to the rest. Nothing happens — the other four finish clean, with no defensive code in the orchestrator, because the isolation boundary does the work. The write-up doubles as a practical guide to registered images, which cut boot times from 19.49s to 4.51s.

An orchestrator/worker architecture for Claude-managed agents that run for days: workers checkpoint their state and suspend when idle instead of holding warm compute. The core claim — state matters more than compute — reframes long-running agents as a persistence problem rather than an uptime problem, and the economics follow from there.

This one found us on its own. Sundaram built an AI coding assistant in Node.js and TypeScript with the Anthropic SDK: it writes, runs, and exports code in Python, JS, TS, and Bash inside a Tensorlake sandbox, with a web UI that streams the agent's thoughts and tool output as it works. The demo is 53 seconds; the code is public if you want to see how the agent loop is wired.

The RL-training version of the snapshot argument: build the environment once, snapshot it, and fork every rollout from that image. Across 8,000 rollouts for a coding agent, Sebastian's setup drops environment time from roughly 20 hours of naive rebuilds to about 4.4 hours — the difference between an overnight run and a same-day iteration loop.

Maybe the strongest kind of endorsement a sandbox can get: adoption as an integration. Sid Palas — of DevOps Directive — added Tensorlake as a sandbox provider in Deputies, an open-source control plane for delegating engineering work to background agents, after a conversation with Diptanu showed it met every criterion from Sid's "What Makes a Good Sandbox for Background Agents" post. Tensorlake now sits in the provider list alongside Daytona, Docker, Kubernetes Agent Sandbox, and AWS Lambda microVMs.

Divy's numbers on why multi-agent systems feel slow: the bottleneck isn't concurrency, it's setup overhead repeated per agent. At 50 agents that's 4,500 seconds spent preparing to work; forking each agent from one memory snapshot cuts it to 50. The longest read in this list, and the most thorough on the arithmetic.

The gentlest on-ramp in this list: a build-along tutorial that starts with a toy code interpreter and upgrades it step by step until it remembers state across sessions, suspends, snapshots, and forks. Everything runs on the free tier, so you can follow along without a card.

Darshan runs five experiments feeding hostile, LLM-generated code to a sandbox and checks whether the walls hold. All four isolation boundaries do, with latency receipts kept throughout: boots average 1.121s with only 148ms of variance. A good first read if you're deciding whether agent-generated code needs a microVM or just a container.

The most complete comparison of agent-sandbox platforms we've seen: eight providers benchmarked head-to-head. The core argument is that tail latency matters more than the leaderboard number — a sandbox that's fast on median but erratic at P99 will stall a multi-step agent in production. Tensorlake places fourth on raw cold-start speed and first on consistency, with a 0.09s median-to-P99 spread against 0.37s+ for everyone else.

Divy builds a research agent that keeps its working state inside the sandbox rather than in the harness, then kills it and restarts it to prove it resumes mid-task. What makes it worth the read is the instrumentation: real latency numbers at every step, not vibes.