1. The author is untrusted. Model-written code can carry an injected payload, a hallucinated rm -rf /, or a typo'd dependency that resolves to malware. You can't read every run.
2. Blast radius is bounded. The box decides what the code may touch — filesystem, network egress, secrets, and (if isolation is weak) the host kernel itself.
3. Reproducible, at scale. Identical clean state every run, thousands in parallel, cheap to spawn and kill. Without it, an eval's reward signal is just noise.

Containment is only half the story. A sandbox is also the whole computer an agent works inside — one place to dev, test, build and deploy, where it takes a task end to end with no human in the seat.

edit → run → test → build → deploy → observe ↺the agent's loop — repeated autonomously, thousands of times over

Docker packaged the artifact: build, ship, run. The sandbox hands the agent the entire workflow — and the keys. Give it a box that can only run code and you get a calculator; give it one that can edit, build and ship, and you get a developer.

Four jobs people actually reach for them:

1. devThe harness's workshopGive the coding agent — Claude Code & friends — a box to develop in: edit, install, run, break things, without touching your laptop or your main branch.
2. test · evalProve it worksRun code you or your AI just wrote on a clean slate and grade it, before you trust a single line.
3. deployShip AI-written codeRun model-authored code in production inside a contained runtime, where its blast radius is bounded by design.
4. parallelTen at onceFork one environment ten ways and let agents chase ten features and bugs at the same time. Keep what passes; bin the rest.

And the same primitive, by role — pick yours:

The boundary decision Untrusted code with nothing to steal belongs outside — a public, ephemeral box, lowest blast radius. Untrusted code that needs your data belongs inside the VPC, isolated hard — now you're fencing something with real network reach.

An isolation ladder — weak & fast at the bottom, strong & heavy at the top. Pick the lowest rung that holds your threat model.

1. subprocess + limitsSame kernel, same user. A timeout and a ulimit. Trusted code only.
2. namespaces · cgroups · seccompnsjail, bubblewrap. Cheap kernel-level fencing for semi-trusted code.
3. containerrunc / containerd. Shared kernel — one kernel CVE is an escape.
4. gVisorA user-space kernel intercepts syscalls. Container ergonomics, smaller attack surface.
5. microVM · FirecrackerA real VM boundary that boots in ~100 ms, thousands per host. The agent sweet spot.
6. full VM · air-gappedMaximum isolation, maximum cost. For the genuinely hostile.

isolation strength↔boot latency↔density / cost

microVMs broke the old rule that VM-grade isolation must be slow and expensive — which is what makes per-run disposability economically real.

the real lessonDocker didn't beat LXC on isolation — it won on developer experience. Sandboxes get won the same way: the best API and the fastest boot, not the thickest wall.

Four questions. Live verdict, recommended rung (it highlights the ladder), and placement. Nothing leaves your browser.

A vast, fast-moving market — converging on the same shape: fast, disposable, API-driven isolation.

Daytona · E2B · Blacksmith · Tensorlake · exe.dev · Modal · islo.dev · …

Pick any of them and the concepts on this page don't change. crabbox.sh exists so you don't have to choose blindly — it runs the same task across every provider, turning the sandbox into a commodity you can swap.

full disclosureislo.dev is one of these providers — and it's ours. There's only one bear in town. 🐻