The browser script reached the Export button and clicked it without complaint. Then a save dialog opened outside the page, and the script waited there with no selector that could reach it. By morning the job had timed out, and the report never arrived.
That failure marks the line between a web page and a computer. Once a job touches a native dialog, a desktop application or a widget that answers only to a real pointer, the agent needs a screen. Solari runs that screen as Computer Desktops: a full Linux computer per agent, driven by mouse, keyboard and screenshots, from the same account as its cloud browsers and sandboxes. This guide covers the signs that a job has outgrown the page, how an agent works a screen, and how to hold a desktop through long waits.
Where Page Automation Stops
The first question is what a browser script can actually see. Playwright and CDP talk to a page through the Document Object Model, the tree of elements a browser builds from HTML, so a script finds a button by its selector without looking at pixels. In a headless browser that is quick and precise, and for work inside web pages it remains the right tool.
The trouble starts at the edges of that tree. A print or save dialog belongs to the operating system, not the document. A chart drawn with the Canvas API is a bitmap, so its bars have no elements to select. Those edges are where the warning signs come from.
Signs a Job Needs a Desktop
Those edges turn into a short checklist that usually shows in the task description before any code is written. A job needs a desktop when it includes any of these:
A file, print or download dialog that opens outside the page.
A desktop application with no web version and no API.
A canvas or plugin widget that responds to pointer movement, not selectors.
A workflow that crosses programs, such as a download in Chrome processed in a terminal.
A job with none of these belongs in a browser, and code-only work belongs in a sandbox, the screen-free sibling with the same lifecycle. A job with any of them is cheaper to run on a desktop than to patch with workarounds, and the agent's loop changes once it has one.
What Changes When the Agent Works a Screen
Moving to a desktop changes how the agent perceives the job, from reading elements to reading pixels. The figure below sets the two approaches side by side.
On a Solari desktop each step is a call in the desktops docs: screenshot() returns an image for the model, mouse.click() takes coordinates, and keyboard.type() sends text. Passing humanize: true gives the pointer a curved path, which helps on sites that watch how the pointer moves. The default image ships with Google Chrome and the XFCE terminal, so a job that starts on the web and ends in a shell stays on one machine.
A teammate can follow along in the live view, whose stream URL is a credential that lets its holder drive the VM as root. The real cost of seeing is time, because every step waits for a model to read an image, and those waits are why the lifecycle settings matter.
Keeping a Desktop Alive Through Long Waits
A computer-use run spends much of its life idle, waiting on a model, a tool call or a person reading the screen. On top of the idle timeout, Solari gives each VM three opt-in levers for those gaps.
The first is parkAfterMs, which freezes the VM's CPUs after a short idle spell while its slot, network connection and live stream stay in place, so the next action wakes it with nothing to restore. A parked VM still counts against the plan's limit on running VMs, so parking suits short waits. The second, hibernateAfterParkedMs, escalates a long park to a full pause, with state saved and the slot freed.
The third, checkpointEveryMs, takes a durable checkpoint on an interval, so a host problem costs one interval of progress rather than the whole run. Coming back from a full pause takes about 1.3 seconds on the same host, measured on staging across five trials.
One rule overrides all of this: if code inside the VM powers it off, the VM is deleted with its disk. Pause, never power off when the agent means to come back, and the next question is what those hours cost.
What a Desktop Costs to Run
Desktop billing follows the time a VM runs, so the settings above translate straight into the bill. Solari bills VMs by size, at $0.0245 per vCPU-hour and $0.0077 per GB-hour on the Professional plan, plus $0.02 per hour for the live screen, as the pricing page sets out. A paused VM frees its place against the plan's limit.
The size chosen at create time sticks through pause and resume, so it pays to size each VM for the app it runs. For a prototype, the Free plan includes $3 of monthly credits, and at a zero balance new desktops stop launching instead of running up an overage. That leaves a short rule for the choice.
Choosing the Right Setup
Keep work inside web pages in a cloud browser, where selectors beat screenshots on speed, and keep code-only work in a sandbox. Move a job to a desktop the moment it touches a native dialog, a desktop application, a canvas widget or a second program. Park for short waits, pause for long ones, checkpoint long runs, and never power off a VM the agent will need again. All three surfaces come from one account and one API, as the Solari introduction describes.
Get Started With Solari
Start with the job that keeps failing at the edge of the page: open a desktop for it and watch the agent's first run in the live view. Solari starts a VM in about a second and bills it by size at the rates above, so a desktop costs little to try. Create a free Solari account and the Free plan's credits cover the first runs.
