Compute sandbox

An isolated, disposable execution environment the platform creates on demand to run code it does not trust — most often code an LLM agent just wrote. Isolation can be a container (Modal Sandboxes) or a microVM (AWS’s Firecracker-backed offering, cloud-wiki’s [[aws-lambda-microvms]]), and the lifetime is typically seconds to minutes.

Why it lands in this spoke

The sandbox is the spoke’s third production substrate, after Kubernetes and serverless functions, and it has an operating profile neither of the others has: the workload is untrusted, the unit is ephemeral, and demand arrives as a burst rather than a curve — a reinforcement-learning run or an agent fan-out wants a million of them at once and none a minute later (modal-1m-sandboxes). That combination is what makes the sandbox a scheduling problem rather than a capacity problem (container-scheduling).

Placed against the rest of the corpus: a sandbox is the isolation boundary that serverless gets from the account and Kubernetes gets from the namespace, pushed down to a single execution and made cheap enough to create by the million.

The unresolved part

Nothing in the corpus yet covers operating these fleets rather than creating them — what observability over a million second-lived sandboxes looks like, whether SLOs on a burst substrate mean anything, what escapes the isolation. The spoke has the creation path (modal-1m-sandboxes) and the vendor surfaces; it does not have an incident, a postmortem, or a neutral measurement.

Adjacency

Sandboxes as products to rent are cloud-wiki’s ([[aws-lambda-microvms]], Modal, E2B). Sandboxes as containment for a harness’s agent are agentic-tooling-wiki’s ([[cloud-run-sandboxes]], WASM containment). The substrate and its scheduler are here.

Related

modal · modal-1m-sandboxes · container-scheduling · serverless · kubernetes · platform-ops · service-level-objectives