The coding agent finished the to-do app and reported that every test passed. Nobody had opened the app in a real browser, and the staging login it needed lived in a sandbox that was deleted, cookies and all, when the run ended. The code had a good home; the browsing did not.
Pairing a sandbox with a separate browser session splits the agent's work in two: the sandbox runs the code, the files and any app the agent serves, while a cloud browser outside it opens pages, keeps logins and records what it saw. Solari offers both from the same account and API key, so the split adds a client to the code, not a vendor to the stack. This guide walks through when to split, how the browser reaches the app, where logins live, what it costs and how to debug it.
When to Split the Browser Out of the Sandbox
The first decision is whether the browser belongs inside the sandbox at all. A browser installed next to the code reaches the agent's app on localhost with no network setup, which is the quickest way to check a page the agent just built. The two layouts trade off like this:
The memory row bites first: a browser rendering heavy pages competes with the build, the test runner and the app for the same RAM. The logins row decides the rest, because a sandbox torn down after each task takes its cookies with it. Once either matters, the browser moves out, and the next question is how it finds the app.
How the Browser Reaches the Sandbox's App
A separate browser cannot see the sandbox's localhost, so the sandbox publishes the port instead. On Solari, previewUrl(port) returns a signed preview URL for whatever the sandbox serves on that port, and a browser session opens it like any other page:
The token in the URL lasts an hour, and the first request that uses it sets a host-scoped cookie, so the page's own scripts and styles load without extra work. A 425 Too Early means the app is not listening yet, so poll; a 401 means the token expired, so ask for a fresh URL. Anyone who holds the URL reaches the port until it expires, so it stays out of logs. With the route open, the remaining question is which side holds the browser code.
Where the Browser Code Runs
The browser can be driven from outside both machines or from inside the sandbox, and each choice has a cost. An orchestrator outside drives the Solari sandbox and the browser side by side, which keeps the API key out of the sandbox and suits a fixed pipeline.
When the agent decides what to browse, its code runs inside the sandbox and launches the session there. That needs outbound network to the Solari API, so the default "dedicated" isolation works and "hardened", which blocks all outbound traffic, does not. Code that already owns a Playwright client can attach with connectOverCDP on the session's cdpEndpoint, which is a credential like the preview URL. Either way, the login the agent needs should not depend on how long the sandbox lives.
Keeping Logins After the Sandbox Is Gone
A sandbox built per task is disposable by design; the account it signs into is not. A Solari profile saves the login, the cookies and site data in Playwright's storageState format, and a session created with profileId starts signed in, whichever sandbox launched it.
The rule that trips people up is that a profile seeds only the session's default context. Use session.context or session.newPage(); a context made with newContext() starts empty unless session.storageState is applied to it. Since a profile holds a real login, a separate API key per environment limits who can act as that account. With logins settled, the split has two meters to watch.
What the Split Costs
Each half bills on its own meter, which makes the split easy to tune. On the Professional plan, Solari bills sandboxes at $0.0245 per vCPU-hour and $0.0077 per GB-hour and browsers at $0.07 per browser hour, with the $200 monthly fee returned as usage credits. The same plan runs 150 concurrent browsers and 10 sandboxes or desktops.
The browser bills only while its session is open, so the habit that saves the most is closing it from a finally block as soon as the page work ends. The sandbox pauses on idle by default, so a quiet agent stops using compute without losing its state. The last piece is seeing what the browser did when a run goes wrong.
Watching What the Browser Did
A sandbox reports exit codes and output, but a page that rendered wrong leaves nothing in stdout. Session recording is an opt-in flag at launch; after the session closes, a replay URL shows the run, and the replay downloads as a line-by-line log of what happened on the page. Recording captures input values by default, so record the sessions that test the app and leave it off for any that type a password. That closes the loop from code to page to evidence.
Choosing the Right Setup
Pairing a sandbox with a browser comes down to memory, logins and visibility. Keep the browser inside the sandbox for a quick check of the agent's own app, and move it to a separate session once pages get heavy, logins must survive teardown or a run needs a replay. Publish the app through a preview URL, keep the login in a profile on the default context, and close the browser the moment its work ends. The Solari launch overview shows how browsers, sandboxes and desktops share the same account.
Get Started With Solari
Start by serving the agent's app on a sandbox port and opening its preview URL from a Solari browser session with the snippet above. Solari is built to be the fastest and cheapest home for this pairing: it starts browsers in 8 ms and sandboxes in 90 ms, and the Free plan includes $3 of monthly credits, so the first paired run costs nothing. Create a free Solari account and run the split today.
