Simon Willison · 2026-08-19 · notable
Simon Willison — smolvm boots a real VM per task to run untrusted code
Simon Willison tested smolvm 1.8.3 as a sandbox for untrusted Python and JavaScript. Each task gets its own hardware-isolated VM: a full create-run-teardown cycle takes 577-643 ms cold, and about 48 ms on a warm machine.
A hands-on test of smolvm 1.8.3 as a per-task sandbox for code an AI agent should not be trusted to run on your machine.
Key specs
| GitHub stars | 5,532 |
|---|---|
| Warm run | ~48 ms |
| Cold cycle | 577-643 ms |
What is it?
smolvm gives every untrusted task its own Linux virtual machine instead of a shared container. Simon Willison tested version 1.8.3 on one specific job: running Python and JavaScript data transformations that came from a model. The tool is Apache-2.0, written in Rust, and wraps libkrun as its virtual machine monitor.
How does it work?
Each workload boots its own guest kernel on Hypervisor.framework on macOS, KVM on Linux, or the Windows Hypervisor Platform, so smolvm's isolation is enforced by the hypervisor and not by a shared kernel. Images use the OCI format, so any Docker Hub or ghcr.io image can be booted as a microVM. Willison's tests confirmed the limits hold: a 1 GB allocation inside a 256 MiB VM fails, a fork bomb tears down cleanly, and a VM started without the network flag has no network at all.
Why does it matter?
Running code that a model wrote is the awkward part of every agent harness, and warm runs of about 48 ms make a VM-per-task design practical where people usually settle for a container. Willison also found a trap worth knowing: the --overlay flag does not bound writes to the root filesystem, so a guest wrote 4 GB into a 20 GiB disk, and --storage is the flag that actually caps disk use.
Who is it for?
agent and developer-tool builders
Try it
curl -sSL https://smolmachines.com/install.sh | bash