The build server ran out of disk overnight, and the culprit was not a build. The coding assistant had been testing its own scripts on the same host, caching datasets in a home directory and leaving a dev server listening on a port nobody had opened on purpose.
Nothing malicious happened; the assistant had borrowed a machine meant for something else. An agent sandbox is the machine it should have had: an isolated computer, created by API for a task, where an AI agent runs the code it writes, keeps its work between steps and reaches nothing it was not given. Solari runs AI Sandboxes as microVMs from the same account as its cloud browsers and desktops. This guide takes a sandbox apart into the four parts each has and shows what they look like on Solari.
What Makes a Sandbox an Agent Sandbox
The term comes from security, so its older meaning is the place to start. A sandbox separates a running program from everything around it and gives it a controlled set of resources. An agent sandbox adds what an agent needs on top: a way to work, a way to remember and a controlled way out.
The figure maps the four parts to the question each answers.
The wall comes first, because every other part depends on how strong it is.
The Wall Between Agent Code and the Host
The wall decides what a mistake can touch. A container is OS-level virtualization: its processes see only their own slice of the machine, but they share the host's kernel. A microVM gives each sandbox a kernel of its own behind a hypervisor, so code that breaks out of its processes still meets a virtual machine boundary.
Solari runs sandboxes as Cloud Hypervisor microVMs with a dedicated kernel per session, isolated by hardware virtualization through KVM. That is the default dedicated tier. A cheaper shared tier runs each sandbox as a process tree inside a VM shared only with the organization's other shared sandboxes, separated by namespaces and a cgroup.
A strong wall only helps if the agent can still work behind it.
The Hands: How an Agent Works Inside
The hands are the calls an agent uses to act inside the sandbox. On Solari, commands.run runs a command to completion and returns the exit code with stdout and stderr, runCode runs Python and keeps variables and imports between calls, and the files surface reads, writes, searches and watches files.
Two features suit agents that work in many steps. Named shells keep the working directory and exported variables from call to call. Background executions keep a process, its output and its exit status alive after the client disconnects, so a restart on the agent's side does not kill the job. Each of these calls is a few lines in Solari sandboxes.
Work spread over many steps raises the question of what survives between them.
The Memory: What Survives Between Steps
Memory separates a sandbox an agent can return to from a throwaway process. A paused Solari sandbox saves its state and picks up where it left off on the next connect(), while a stopped one keeps its files but not its running state.
A snapshot goes further: it saves disk and memory while the machine keeps running. revert() rewinds the same sandbox to it, and fromSnapshot starts independent copies, so slow setup happens once. A paused machine must be resumed before it can be snapshotted, which is the rule that trips people up. Files that should outlive the machine go on a persistent volume, which keeps its contents after the sandbox is destroyed.
A volume is network storage, which leads to the last part: what crosses the wall.
The Doors: What Gets in or Out
The doors are every path between the sandbox and the outside world. Outbound traffic comes first: the hardened tier is a dedicated microVM with all outbound network blocked, a strict form of egress filtering suited to code nobody has reviewed. Because a volume needs the network, a hardened sandbox cannot attach one.
Inbound access runs through signed links. previewUrl(port) returns a public URL whose token lasts an hour, and a tunnel opens every port of a sandbox at once, authenticated by default. Both act as bearer credentials: whoever holds the link can use it. The sandbox id and its control URLs work the same way and let their holder run commands as root, so all of them stay out of logs, tickets and client-side code.
With the four parts in place, the remaining question is the bill.
What an Agent Sandbox Costs
Solari bills a sandbox for the CPU and memory it runs with, so sizing is the main lever on cost. A 4 vCPU, 16 GB sandbox runs at $0.221 per hour on the Professional plan. The Free plan costs $0 with $3 of monthly credits and room for a sandbox or desktop at a time. At a zero balance, new sandboxes stop launching rather than running up an overage.
Snapshots add storage at $0.05 per GB-month after the first 10 GB, so deleting superseded snapshots is the easiest saving.
Choosing the Right Setup
An agent sandbox is the right home for any code a model wrote, and its four parts make a short checklist. Match the wall to how far the code is trusted: dedicated for everyday work, hardened for unreviewed code, shared for quick commands where cost matters most. Then pick hands that fit the job, choose what survives with pause, snapshots or a volume, and keep the doors as narrow as the task allows.
Get Started With Solari
Start with the job from the opener: create a dedicated sandbox, run the agent's scripts inside it, and snapshot the setup so the next run forks from a clean machine. Solari sandboxes are ready in 90 ms, and over a sandbox's full lifecycle Solari is about 1.3x faster than E2B and almost 3x cheaper per sandbox hour. Create a free Solari account and the Free plan's credits cover the first sandbox.
