An isolated VM
for every run.
Each run gets its own VM with its own kernel, on CPU or GPU. Use it for agents, evals, RL rollouts and load tests. Tensile runs these workloads on Sandbox for you, and Sandbox is also its own product, with its own console and SDK. Training and large inference jobs run on your Kubernetes or Slurm clusters instead.
Containers share a kernel. Untrusted AI workloads shouldn't.
Agents run arbitrary code, evals pull arbitrary models, rollouts touch the network. A shared-kernel container is one escape away from the host. A VM gives every run its own kernel, and it starts in about 220 ms, so you don't have to trade isolation for speed.
Hardware-level isolation
A dedicated guest kernel per run. Tenant and run boundaries are enforced by the hypervisor, not by namespaces.
Fast starts
Cold start in about 220 ms, or resume from a snapshot in about 16 ms. Every run starts on a clean machine.
Small blast radius
A minimal guest with no extra daemons. Less to attack, less to patch, nothing shared with the next tenant.
Provision, run, stream, tear down.
Boot a VM from an image, tied to your organisation and run.
Run the workload harness inside the guest — agent, eval, or rollout.
Logs, traces and artifacts stream back to Tensile as the run goes.
Tear down on exit. Nothing persists into the next run.
from tensile import Sandbox # One VM, scoped to your organisation and runwith Sandbox.launch(image="python:3.12", cpu=4, mem="8Gi") as vm: vm.exec("pip install -e . && pytest -q") # streams live art = vm.collect("./artifacts") # pulled to the registry# → VM reclaimed; nothing shared with the next runAgents, evals, rollouts and load tests.
The same kind of API, on infrastructure you control.
| Tensile Sandbox | Hosted (Modal, E2B, Daytona) | |
|---|---|---|
| Runs on | Your hardware / cloud | Vendor cloud |
| Data boundary | Stays inside your perimeter | Leaves your perimeter |
| Cost model | Your own capacity | Per-second vendor billing |