A customer rang the support desk on Monday to ask why her refund had landed on someone else's account. The agent that keys refunds into the billing client had worked through the night on a shared machine, and by morning the screen had moved on through a long queue of later jobs. The logs showed a click on Save, but nobody could say what the form looked like at that moment.
That question has a clean answer only when every agent session runs on its own machine, recorded from the start. Solari Computer Desktops give each job a desktop per session: a full Linux computer with a screen, created by API, recorded on request and destroyed when the job ends, so the session id indexes everything the agent did. This guide walks through the setup, the lifecycle choices that keep a session reviewable, and the rule about secrets that matters most.
Why a Desktop per Session Beats a Shared Machine
The case for a machine per session starts with what a reviewer needs to trust. A shared desktop carries windows, files and half-finished forms from earlier jobs, so its recording mixes the agent's work with leftovers it never touched.
A Solari desktop is a virtual machine with a stable id, and it starts in about a second. At that start time there is no reason to keep a warm machine between jobs: each refund or order gets a fresh desktop, and nothing on it predates the task. The next step is turning recording on at the right moment.
Starting a Recorded Session
Recording belongs in the create call, because a recording that starts later misses the first screens the agent saw. On Solari the flag is record: true, and since the changelog entry "Reliable desktop session recordings", a desktop created that way returns its recordingUrl on create.
The sketch below creates a recorded desktop, writes the session id and recording link to the job record before the agent acts, and destroys the machine at the end.
Storing the link first means a crashed agent still leaves its evidence behind. What happens between create and destroy matters just as much, since many sessions stop and wait.
Keeping the Session Intact While a Human Reviews
Computer-use jobs often wait for a person, such as a manager approving a refund. The lifecycle settings decide whether the session survives that wait.
If no idle timeout is set, a VM sits idle for 30 minutes before its onTimeout rule applies. With "pause", Solari saves the state and the next connect() picks up where it stopped; with "kill", the machine shuts down. A paused VM also stops counting against the plan's limit on running VMs, so sessions awaiting approval hold no slots.
A further rule protects the record: a VM that powers itself off is deleted with its disk and cannot be resumed. Once the session ends cleanly, the recording has to become something a reviewer can use.
Building the Audit Trail From the Recording
A video shows what the screen held; an audit trail also says when, by which process and for which job. The practical pattern is to log every model step with a timestamp, the VM id, the job id and the action taken, the event attributes the OWASP Logging Cheat Sheet describes.
With those fields in place, a reviewer jumps from a log line to the moment in the recording where the agent clicked. While a session runs, the live view lets a person watch and step in before a wrong entry is saved.
Many desktop jobs also open a cloud browser for web steps. Those sessions record with their own flag, and the browser replay downloads as NDJSON, a line-by-line log of the page that can sit beside the desktop recording under the same job id. Evidence this complete carries its own risk.
What to Keep Out of the Recording
A recording keeps whatever the screen and the inputs held. Solari's browser recording captures input values by default, so a replay of a session that types a password carries it.
The safer design keeps sign-ins out of recorded sessions and gives the agent an account scoped to the job, in line with the least privilege principle. The live-view link is a credential too: on the desktops page, whoever holds a desktop's streamUrl can watch and drive that VM and run commands in it as root, so the link belongs in a secrets store, never in a ticket. That leaves how long recordings stay and what a session costs.
How Long Recordings Stay and What They Cost
Retention is set by plan, so choosing a plan is also a compliance decision. The figure below shows browser replay retention on each plan.
Solari keeps browser replays for the plan windows shown above, with Enterprise matching Team, and a team that keeps evidence longer downloads replays to its own storage. Desktops bill by vCPU and memory while they run, and VMs add $0.02 per hour for the live screen.
Choosing the Right Setup
A computer-use agent is reviewable when each session has its own machine, its own recording and a log that points into it. Create a fresh desktop per job with recording on, store the session id and link before the agent acts, pause rather than power off while a person reviews, and keep secrets and stream links off the screen. The companion piece, Solari for Computer-Use Agents: Isolated Desktops, Recorded Runs, covers the isolation boundary, and the Solari introduction covers the browsers and sandboxes beside it.
Get Started With Solari
The first job to try is a single recorded session: start a desktop with the recording flag, let the agent finish a task, then watch the replay next to its action log. Solari is the fastest and cheapest place to run that loop, with the desktop up in the start time above, billed by size from one credit balance alongside browsers and sandboxes. Create a free Solari account and the Free plan's $3 monthly credits cover the first recorded session.
