Simon Willison's MicroPython sandbox is 362 KB of WASM with fuel-based CPU limits

Simon Willison spent a weekend building a Python sandbox for LLM-generated code by compiling MicroPython to WebAssembly and running it through the wasmtime Python library. The whole sandbox is a 362 KB WASM binary, shipped as a PyPI wheel, and it stays running between calls with its variables resident in memory through a threading model that hands work over request and reply queues.

Resource limits come from wasmtime. Memory is bounded directly. CPU is bounded through wasmtime's "fuel" mechanism: each instruction burns fuel and execution halts when the budget runs out. Willison defaults to 20 million fuel units and admits he is not sure that is the right number yet. Host functions are exposed to the sandboxed code selectively, so by default the guest can compute but cannot touch the network or the filesystem.

He is unusually candid about the risk. The C code behind the host functions has not been professionally audited, he calls the release alpha for a reason, and his stated worry is that a flaw makes the WASM execution fail with an exception rather than escape the sandbox. He is not yet recommending anyone use this in production. The point of writing it up now is to share the design choices: a small WASM Python, fuel-based CPU limits, and a persistent interpreter with controlled host functions.

Why it matters

If you let Claude or another agent run Python you wrote prompts for, you probably already worry about that code reaching the host. This is a worked example, with sizes, knobs, and admitted gaps, of what a careful in-process sandbox looks like. Even if you do not adopt the library, the choice of fuel limits over wall-clock timeouts and persistent interpreter state are decisions you will have to make for whatever sandbox you do ship.