The supplier portal has no API, and its monthly export hides behind a date picker that only answers to a mouse. Somebody in finance has clicked through it by hand at every month end for years, and the ticket asking to automate it carried a short note: whatever does this job has to see the screen.
That note describes a computer-use desktop environment: a cloud computer with a graphical screen that an AI model operates the way a person does, by reading a screenshot and sending back a click or a keystroke. Solari runs these as Computer Desktops, a full Linux computer per agent with a live view, a shell and files, from the same account as its cloud browsers and sandboxes. This guide covers what sits inside the environment, how an agent drives it, how it keeps state, what it costs and how to start one.
What Sits Inside a Desktop Environment
The term borrows from ordinary computing, so the parts are familiar. A desktop environment is the layer of windows, menus and a pointer on top of an operating system, and a computer-use desktop puts that layer inside a virtual machine, so each agent gets a computer of its own.
On Solari, the default image ships with Google Chrome and the XFCE terminal, and the screen runs at 1280×720. The agent also gets a shell, files, the clipboard and the process table, and the desktops docs describe every call. Having the parts is half the picture; the other half is how a model works them.
How an Agent Drives the Screen
A computer-use model works in a loop rather than through page selectors. It takes a screenshot, picks a point on the image, sends mouse or keyboard input, then looks again to see what changed. On Solari each step is a call: screenshot() returns an image, mouse.click() takes coordinates, and keyboard.type() handles text.
A person can watch along too, because every VM comes with a live view, similar in idea to VNC, where a teammate checks a run or takes over the keyboard. Its streamUrl is a credential: whoever holds it can drive the VM and run commands in it as root.
Reading the screen also means reading whatever is on it, and OWASP describes instructions planted in web pages and files as indirect prompt injection, so the desktop should hold no production secrets. With the risks in view, the next question is when a screen is worth it at all.
When a Desktop Beats a Browser or a Sandbox
A desktop is the heaviest environment an agent can run in, so it earns its place only when the job needs more than a web page. The figure below sets the three Solari surfaces side by side.
A browser is quicker for web work because Playwright reaches the page directly and skips the screenshot loop, and a sandbox is enough for code. A desktop covers the rest: a native app, a file dialog, a widget that only answers real pointer input, or a job that moves between a terminal and a browser window. Wherever the job lands, it has to survive the waits between steps.
How a Desktop Keeps State
Computer-use runs wait a lot, on the model, on a tool call or on a person reading the screen, so the environment has to hold its state through those gaps. A Solari VM pauses after an idle timeout that defaults to 30 minutes; a pause saves its state, the next connect() picks up where it left off, and a paused VM does not count against the plan's limit on running VMs. Coming back is quick too, since a same-host resume takes about 1.3 seconds (staging, five trials).
The rule that catches people out is power: if code inside the VM runs poweroff, the VM is deleted with its disk, so an agent that is done for now should pause instead. Held state has a price, which is the next thing to plan for.
What a Computer-Use Desktop Costs
Because a desktop is billed by the time it runs, the bill tracks usage rather than seats. On the Professional plan a desktop runs at $0.060 per desktop hour, with the live screen adding $0.02 per hour. For a first prototype, the Free plan costs $0 with $3 of monthly credits, and at a zero balance new desktops stop launching rather than running up an overage.
Pausing idle VMs keeps the bill down as well, and with the price known, the setup is short.
How to Start a Desktop on Solari
Starting a desktop takes an API key, the @solarisdk/desktop package and a create call that sets the size, where each VM takes 1 to 8 CPUs and up to 16 GB of memory and keeps that size across pause and resume. This sketch starts a VM, opens Chrome on the portal and captures a screenshot for the model.
From there, the agent's loop sends the image to the model and turns its answer into mouse and keyboard calls, and when a step only runs code, the sandboxes docs cover the screen-free sibling with the same lifecycle. That leaves a few rules for the setup itself.
Choosing the Right Setup
A computer-use desktop is the right home for a job that needs a whole screen, such as native apps, mouse-only widgets or work that crosses from a terminal into a browser. Keep web-only steps in a browser and code in a sandbox, give each agent its own VM, pause rather than power off, and treat the stream URL like a password. The browsers and sandboxes that pair with desktops are covered in the Solari introduction.
Get Started With Solari
The first step is to start a desktop, open the app the job needs and watch the agent's first run in the live view. Solari starts a VM in about a second, and the Professional rate above keeps a desktop hour to a few cents. Create a free Solari account and the Free plan's credits cover the first desktop.
