On Sunday evening the assistant got its weekly list: rebook a cancelled train, total the month's receipts into the expense sheet, and renew a parking permit on the city portal. The train site wanted the owner's login, the receipts needed a script, and the permit portal was an old desktop app that only answered real clicks. The owner expected it all done by Monday without being asked to sign in again.
That list is the work of a personal agent: errands for a person, spread across websites, code and desktop software, with quiet hours in between. Solari gives a personal agent app all three places to work from one account and one API: Cloud Browsers that keep each owner's logins, AI Sandboxes for the code the model writes, and Computer Desktops for software with no API. This guide walks through each surface, how state survives the quiet hours, and what it costs.
The Browser Keeps Each Owner Signed In
Most errands start on a website, so the browser comes first, and the hard part is the login rather than the page. A Solari profile saves a browser's cookies and site data in Playwright's storageState format, and a later session reopens it by id, so the agent starts already signed in.
For a personal agent app, the pattern is a profile per owner. The owner signs in once through the profile editor, a live browser opened from a link, which is also the practical route past two-factor prompts. Every later errand attaches the profile when the session is created:
A profile seeds only the session's default context, so a context the agent opens itself starts signed out. A profile is also a real login, so it deserves the same care as a password. Solari browsers are ready in 8 ms, which keeps a quick errand quick; the receipts on the list need something else.
The Sandbox Runs the Code the Agent Writes
Totalling receipts or drawing a chart is code, and code an agent wrote belongs in a sandbox, away from the app's own servers. A Solari sandbox is a Linux machine with no screen, created by API, with commands, files and Git built in, and by default it is a microVM of its own.
The call a personal agent leans on is runCode, which keeps its Python state between calls, so imports and variables from an earlier step are still there in the next. A matplotlib figure comes back as an image the app can show the owner, and Solari sandboxes start in 90 ms.
A sandbox id and its control URLs are credentials that can run commands as root, so they stay on the app's server and never reach the client. The permit portal is the errand left, and it offers neither a page to script nor an API to call.
The Desktop Handles Software With No API
Some errands live in software a browser cannot drive, and that is where a desktop takes over. A Solari desktop is a full Linux virtual machine with a graphical screen, usually ready in about a second, and the agent drives it with mouse, keyboard and screenshots.
Every desktop has a live view. When the portal asks a question only the owner can answer, the app hands the screen to that person, who takes over and hands it back. The stream link grants full control of the machine, so it never goes into chats, tickets or logs.
Solari recording is opt-in and captures input values by default, so a run that types a password stays unrecorded. With all three surfaces in place, the open question is what happens between errands.
Keeping State Through the Quiet Hours
A personal agent spends most of its day waiting, so idle behaviour shapes both the experience and the bill. Solari desktops and sandboxes share a lifecycle: after an idle timeout the machine pauses by default, its state is saved, and the next connect picks up where it stopped.
Pausing also frees capacity. A paused VM doesn't count against the plan's limit on running VMs, so for an app with many owners, a paused machine holds no slot while its owner is away.
Two habits keep that safe. A parked VM, meant for short waits such as a model call, freezes its CPUs but still counts against the limit. And a desktop that powers itself off is deleted with its disk, so the app pauses, never shuts down, a machine it wants to keep. That leaves the cost.
What a Personal Agent App Costs
Profiles are the first plan limit a personal agent app meets, because it needs a profile for every owner. The figure shows how many each plan holds.
On the Solari plans, Free holds 3 profiles, Starter 20 and Professional 500, and Team has no cap. The Professional plan bills $0.070 per browser hour, $0.221 per sandbox hour at 4 vCPU and 16 GB, and $0.060 per desktop hour, and its $200 fee covers $200 of usage.
With the pausing habit from the previous section and a browser released at the end of each errand, the bill tracks the time the agent works rather than the hours it waits.
Choosing the Right Setup
A personal agent app needs a place for each kind of errand: a browser with a saved profile for the web, a sandbox for the code the model writes, and a desktop for software with no API. Give each owner their own profile, keep every credential on the server, and pause machines between requests instead of shutting them down. The Solari introduction shows how the three surfaces sit under the same API, and a companion guide on choosing between a browser, a sandbox and a desktop covers the split in more depth.
Get Started With Solari
Start with the browser: create a profile for a test account, sign in through the editor, and run a single errand with it attached. Solari is the fastest and cheapest place to grow that app, with browsers ready in the 8 ms noted above and the Professional browser rate above, all on one account and one bill. Create a free Solari account and the Free plan's credits cover the first errands.
