AI Sandboxes Explained: Lifecycle, Pause and Resume, Files and Limits

The data-cleaning agent had spent the afternoon installing libraries and loading a messy export into memory when it stopped to wait for an answer from finance. The answer would not come until morning. Leaving the machine running overnight felt wasteful, and throwing it away meant paying for the whole setup again.

That choice is what a sandbox's lifecycle decides. An AI sandbox is an isolated Linux machine an agent creates by API to run code, move files and keep state, and its lifecycle sets what survives a pause, a snapshot or a shutdown. Solari runs AI Sandboxes with pause and resume, snapshots, revert and fork, from the same account as its cloud browsers and desktops. This guide follows a sandbox from create to teardown, then covers files, limits and the bill.

How a Sandbox Moves From Create to Teardown

Every later stage hangs off the create call, so it comes first. A sandbox in the security sense separates running programs from everything around them. On Solari it starts from a template through the @solarisdk/sandbox package, and the same create call sets the idle rule:

const sbx = await sandboxes.create({
  template: "base",
  idleTimeoutMs: 15 * 60 * 1000,
  lifecycle: { onTimeout: "pause" }, // or "kill"
})
await sbx.connect()

const sbx = await sandboxes.create({
  template: "base",
  idleTimeoutMs: 15 * 60 * 1000,
  lifecycle: { onTimeout: "pause" }, // or "kill"
})
await sbx.connect()

const sbx = await sandboxes.create({
  template: "base",
  idleTimeoutMs: 15 * 60 * 1000,
  lifecycle: { onTimeout: "pause" }, // or "kill"
})
await sbx.connect()

Activity resets the idle clock, and when it runs out, onTimeout decides the outcome. The default, "pause", saves the machine and keeps it resumable, while "kill" shuts it down for good.

The difference between those two outcomes is where most of the design work sits.

What Pause and Resume Keep

Pausing is the stage that answers the overnight question from the opener. It works like hibernation on a laptop: memory and running processes are saved, and resume() or the next connect() brings the sandbox back exactly as it was, at the same size. A paused machine is never shut down for being idle, and on the lifecycle sandboxes share with Solari desktops, it does not count against the plan's limit on running machines.

Resume speed depends on timing. On VMs, which run the same lifecycle, a same-host resume took about 1.3 seconds on staging across five trials once the pause had finished saving, while a resume called mid-pause waits its turn and runs slower.

Pause keeps a single moment, though, and agents often need several.

How Snapshots, Revert and Fork Work

Snapshots cover what pause cannot, which is keeping several moments at once. A snapshot on Solari is a named save point holding a full disk and memory image, taken while the machine keeps running. revert rewinds the same sandbox to it, and fromSnapshot starts independent copies, so an agent can install dependencies once and fork ready workers:

const snapId = await sbx.snapshot("after-setup")
await sbx.revert(snapId)
const worker = await sandboxes.create({ template: "base", fromSnapshot: snapId })

const snapId = await sbx.snapshot("after-setup")
await sbx.revert(snapId)
const worker = await sandboxes.create({ template: "base", fromSnapshot: snapId })

const snapId = await sbx.snapshot("after-setup")
await sbx.revert(snapId)
const worker = await sandboxes.create({ template: "base", fromSnapshot: snapId })

One rule trips people up. A paused machine has no live VM to capture, so snapshot() and revert() on it return 409 NotRunning; resume first, then snapshot.

With state handled, the next question is how an agent gets work in and out.

Moving Files and Running Commands

Getting work in and out runs through files and commands, and Solari splits them by job. The files surface writes, reads, lists, searches and watches guest files, with upload and download for larger blobs. commands.run runs a command to completion and returns the exit code with stdout and stderr, while commands.start streams output from long-running processes.

Two helpers keep state between calls: runCode remembers Python variables and imports, and named shells keep the working directory and exported variables across commands.

Each of these surfaces has a ceiling worth knowing before a production run.

The Limits That Catch People

Most of those ceilings depend on the isolation tier, so the figure sets the two common tiers side by side.

Dedicated, the default, is a microVM of its own, while shared runs as a process tree in a VM used by the organization's other shared sandboxes, held apart by namespaces and cgroups. A create above either ceiling is rejected with a 400 rather than quietly reduced. Shared memory is also a hard cap the guest cannot see, so code that sizes itself from /proc/meminfo can overcommit and be killed.

Command limits apply on every tier: a one-shot command defaults to a 10-minute deadline and returns timedOut: true instead of throwing, a sandbox holds at most 8 named shells, and up to 16 background executions run at once.

Ceilings set what a sandbox can do; the bill sets how long it is worth keeping.

What a Sandbox Costs

That bill follows from the size chosen at create time: Solari charges sandboxes for the vCPUs and memory they run with, and the rate falls as the plan grows.

Solari bills memory at $0.0077 per GB-hour on Professional, and the Free plan includes $3 of monthly credits with no end-of-month overage charge. Snapshots add storage at $0.05 per GB-month after the first 10 GB, so deleting superseded snapshots is the simplest saving.

Choosing the Right Setup

The lifecycle comes down to a few habits. Create each sandbox at the size the job needs, let idle sandboxes pause rather than die, snapshot after slow setup and fork workers from it, and resume before any snapshot or revert. Pick dedicated isolation when the agent needs files or manual pause, and shared only for quick commands. The Solari introduction shows how the same account pairs a sandbox with a browser.

Get Started With Solari

The first step is to start a dedicated sandbox, run the agent's slow setup once, snapshot it and pause it until the next job. Solari sandboxes are ready in 90 ms and run almost 3x cheaper than E2B per sandbox hour. Create a free Solari account and the Free plan's credits cover the first sandbox.