The reconciliation agent had finished in the bank portal and now needed to open the downloaded statement in a desktop app, run a cleanup script over it, and leave everything in place for the finance lead to check the next morning. A browser tab could not hold that job, and the container it borrowed on the shared cluster lost its files the moment the node restarted.
That job needs a VM. A VM for an AI agent is a full virtual computer, with its own kernel, disk and memory and optionally a screen, that the agent starts by API, works inside, pauses and resumes. Solari runs them as Computer Desktops, VMs with a graphical screen, and AI Sandboxes, the same machine without the screen, from one account and one API. Here is what a VM gives an agent, which kind to pick, and how to run one.
What a VM Gives an Agent That a Container Does Not
The first question is why an agent needs a whole machine when a container starts quickly and costs little. A virtual machine is a complete computer emulated on a host, and a hypervisor keeps each guest apart from its neighbours. A container shares the host's kernel and is separated from other processes by Linux namespaces and cgroups, a thinner wall for code nobody has reviewed.
Agent-generated code is exactly that kind of code. Each Solari session runs in a Cloud Hypervisor microVM with a dedicated kernel, so a bad command breaks the agent's own machine and nothing else.
Solari sandboxes come in three isolation tiers. "Dedicated" is the default, a microVM of the agent's own; "hardened" is the same machine with all outbound network blocked; "shared" is a cheaper process tree inside a VM shared only with the same organization's other shared sandboxes. With the boundary settled, the next choice is whether the agent needs a screen.
Desktop VM or Sandbox: Which One an Agent Needs
The two surfaces differ in one thing, the display, and that decides which jobs each fits. The figure below sets them side by side.
A desktop is the right machine when the agent works through pixels. A Solari desktop is a full Linux computer with mouse and keyboard input, screenshots, a shell, files and the clipboard, and its default image ships with Google Chrome and the XFCE terminal. A live view streamed over VNC lets a person watch the agent and take over.
A sandbox is the right machine when the agent only writes and runs code. It runs commands, keeps Python state between runCode calls, clones and commits with Git, and reads and writes files. Both surfaces share the same lifecycle, which is where a VM earns its place on long jobs.
How to Start a VM and Keep Its State
Starting a machine is a single create call, and Solari has a VM ready usually in about a second. The call sets a template, a size from 1 to 8 CPUs and an idle policy; a size above that range is rejected with a 400, not quietly reduced.
The two calls that matter most on a long job are create with an idle policy, and pause by hand.
Pause is the setting to understand. It saves the machine's state, and a paused VM stops counting against the plan's limit on running VMs until it resumes. Without a timeout set, a VM pauses after 30 minutes of no activity, and a same-host resume takes about 1.3 seconds once the pause has finished, measured on staging over five trials. Powering a VM off from inside deletes it with its disk, so an agent that wants its work back pauses and never shuts down.
For short waits, such as an LLM response, parkAfterMs freezes the CPUs while the connection and live view stay held. A parked VM still counts against the running limit, so it is a latency tool rather than a cost tool, and cost is the next question.
What VMs for AI Agents Cost
Solari bills sandboxes and VMs by size, so a small machine costs a fraction of a large one. The figure shows the per-vCPU-hour rate on each plan up to Team.
On Professional, memory adds $0.0077 per GB-hour to the vCPU rate above, and a desktop VM adds $0.02 per hour for the live screen. Every product draws from one credit balance that refills monthly, and at a zero balance new machines stop launching instead of running up an overage charge.
Professional runs 10 sandboxes or desktops at once, and the Free plan runs a single machine on $3 of monthly credits, enough to prototype before the limits below matter.
Limits Worth Knowing Before Production
A VM is a real computer, so its access links deserve the care given to a root password. Anyone holding a desktop's streamUrl can watch it, drive it and run commands as root with no further check, which makes it a credential to keep out of logs, tickets and chat.
Session length depends on the plan: Professional caps a session at 24 hours, while Team and Enterprise run sessions with no cap. Agents that pause by hand, work with files or stream output run on the dedicated tier, which supports all three.
Choosing the Right Setup
The decision comes down to two questions: does the agent need a screen, and does its work need to survive a pause. A computer-use model that clicks through applications belongs on a desktop VM, while code written by a model belongs in a sandbox on dedicated isolation. Whichever machine the job lands on, the same three habits keep it safe and cheap: an idle policy that pauses, a size set at create time, and every stream URL treated as a secret.
Get Started With Solari
The first step is a single sandbox or desktop on the Free plan, created with pause as its idle policy, then the same job run again after a resume. Solari sandboxes are about 1.3x faster than E2B over a full lifecycle and almost 3x cheaper per sandbox hour, and the Solari launch overview shows how browsers, sandboxes and desktops share one account. Start free on Solari and give the agent a machine of its own.
