Sandboxes for Long-Running AI Agents (2026 Guide)

The migration job was most of the way through rewriting the orders table when the laptop that launched it was closed for the commute. The connection dropped, the job died with it, and the morning started with a rerun from the top.

Long-running agents fail this way more often than they fail on logic: the work outlives the client, the idle timer or the host it started on. A sandbox built for long runs is an isolated Linux machine whose processes keep going after the client leaves, whose memory survives a wait, and whose progress survives host trouble. Solari runs AI Sandboxes that do all three, from the same account as its browsers and desktops. This guide walks through the settings that decide what a long job keeps, and the rule that trips people up.

Keep the Job Running When the Client Leaves

The first thing a long job needs is to stop depending on the process that started it. A sandbox separates running programs from everything around them, and on Solari that separation extends to the client. A command started through POST /sandboxes/:id/executions runs on a channel the gateway owns, so the process, its output and its exit status survive the client disconnecting, and the agent polls, waits or follows the stream when it reconnects.

The everyday call has a trap. In the Solari sandboxes API, commands.run gives each command a 10-minute deadline by default and returns timedOut: true instead of throwing when it hits it. A job meant to run for hours goes through the executions endpoint or turns the deadline off:

const res = await sbx.commands.run("python", {
  args: ["migrate.py"],
  timeoutMs: 0, // no deadline
})

const res = await sbx.commands.run("python", {
  args: ["migrate.py"],
  timeoutMs: 0, // no deadline
})

const res = await sbx.commands.run("python", {
  args: ["migrate.py"],
  timeoutMs: 0, // no deadline
})

Execution records stay readable after exit, with a tail of standard output and error, so a reconnecting agent can still see how the job ended. Background executions run on dedicated isolation, the default. A job that keeps running still has to decide what happens while the agent waits.

Decide What Happens While the Agent Waits

Waiting is where most long runs spend their hours: on a model call, a tool or a person. The idle timer decides the outcome, and every action or open connection resets it. When it runs out, onTimeout: "pause", the default, saves the machine, while "kill" ends it for good.

Pause works like hibernation on a laptop: memory and running processes are saved, and the next connect() brings the sandbox back exactly as it was. A paused machine does not count against the plan's limit on running machines, and on staging, across five trials, a same-host resume took about 1.3 seconds once the pause had finished saving.

A pause frees the slot but costs a restore, which is heavy for waits measured in seconds.

Use Park for Short Waits

Short waits get a lighter lever, part of the lifecycle sandboxes share with Solari VMs. parkAfterMs freezes the machine's CPUs after a stretch of idle time while its slot and connections stay held, so the next touch wakes it with nothing to restore. The trade is the slot: a parked machine still counts against the plan's limit, the same as an active one.

hibernateAfterParkedMs escalates a park that runs long into a full pause, which frees the slot. A short park paired with a hibernate setting of 15 minutes is a sensible starting point, tuned later against the job's real idle gaps.

Park and pause handle waiting; neither protects the job if the host underneath it has a problem.

Protect Progress With Checkpoints and Snapshots

Host trouble is the failure no idle setting covers, and checkpoints are the answer to it. With checkpointEveryMs set, the machine takes a durable checkpoint on that interval, so a host issue costs at most one interval of progress. Each checkpoint briefly pauses the guest, so a very short interval spends the run stuttering instead of working.

Snapshots are the manual version: a named save point holding the full disk and memory, taken while the machine keeps running. An agent can snapshot before a risky step and revert if it goes wrong, keeping the same sandbox id. The rule that trips people up is that both calls need a running machine; on a paused one they return 409 NotRunning, so resume first.

Every one of these levers also shapes the bill, which is the last thing a long run has to answer.

What a Long Run Costs

Cost follows from how long a sandbox runs and how big it is, so the levers above double as the bill's controls. Solari charges sandboxes $0.0245 per vCPU-hour and $0.0077 per GB-hour on the Professional plan, and bills a Professional sandbox hour at 4 vCPU and 16 GB at $0.221.

Size the sandbox for the job's peak, not its waits, and let pause take the waits off the running count. Stored snapshots bill at $0.05 per GB-month after the first 10 GB, so deleting superseded ones is the simplest saving.

Choosing the Right Setup

The levers line up by what each keeps and whether it frees the plan's running slot.

Start long jobs through the executions endpoint or with no command deadline, let waits of seconds park and waits of minutes pause, and set a checkpoint interval on any run whose rerun would hurt. Snapshot before risky steps, and resume before any snapshot or revert. The same Solari account also runs cloud browsers for long jobs that need the web.

Get Started With Solari

The first step for a long-running agent is a dedicated sandbox with pause on idle and a checkpoint interval, with its main job started through the executions endpoint. The Solari site says sandboxes are ready in 90 ms, and they run almost 3x cheaper than E2B per sandbox hour, so long runs cost less and restart faster. Create a free Solari account and start on the Free plan at $0 a month with $3 of monthly credits.