The problem
I built the Solari suite as four Python packages around a cloud-browser platform. The pieces cover diagnostics and benchmarks, a browser-use adapter, an agent that builds and playtests web games, and CI sizing. The useful question was not only whether an agent could complete a browser task. It was whether the platform exposed enough of its isolation, proxy, session, cost, and execution behavior to make that task reliable.
The playtest package builds a web game from git in a sandbox, plays it in cloud Chrome, and reports over MCP. That gave the suite a concrete workload. It also made platform failures visible in a way that a synthetic check might not: the playtest agent found the vault-team roster bug unaided, where div.rosterpanel reopens at 320×4 px.
Architecture
solari-lab provides the solab CLI, diagnostics, benchmarks, isolation and proxy checks, cost tracking, and an HTML report. solari-browser-use is a one-constructor swap for browser-use on Solari and shipped with clean_start=True, which wipes CDP storage. solari-playtest owns the build, play, and MCP reporting loop. solari-ci sizes GitHub Actions at 1, 2, 4, and 8 vCPU.
The packages are versioned together at v0.1.0, use Python 3.11 or newer, and are built with hatchling. The split keeps a diagnostic result separate from the adapter and from the end-to-end playtest workload. It also gives the CI sizing work a narrow place to live instead of mixing it into browser behavior.
Try it
A recorded session of the solab CLI's help and subcommands.
Recorded terminal session
Decisions
Split the suite into four packages
I kept the four responsibilities separate so a diagnostic CLI, a browser-use integration, an end-to-end playtest, and GitHub Actions sizing can evolve without becoming one undifferentiated tool. Alternative considered: one package with all four paths behind a single interface.
Start browser sessions clean by default
The browser-use adapter shipped with clean_start=True and a CDP storage wipe. The point is to make a new session begin without carrying state from an earlier one. Alternative considered: reuse the profile for faster setup, which would make state leakage harder to distinguish from application behavior.
Report playtests over MCP
The playtest agent reports over MCP so the result can be consumed as part of the wider agent workflow. The game is built from git and played in cloud Chrome before the report is emitted. Alternative considered: keep the run as a local script and require a separate manual handoff.
Security / reliability
The security and reliability work changed what I trusted about the platform. A released-session Chrome profile could leak across sessions on the same host. I reproduced it with four sessions; the issue was later scoped to a per-organization pool and marked medium severity. The session id is the sole credential for the CDP websocket, and it is logged; the ids embed internal private IPs.
The timing and timeout behavior also needed correction. The claimed 8 ms spin-up measured 1930 ms cold and 614 ms warm. Raw-CDP sessions die at roughly 10–13 minutes without documentation. Proxy tiers changed under measurement in one day. An undocumented roughly 28-second sandbox exec cap poisons the exec path because a long-running command can fail for a platform reason the caller cannot see.
Numbers
What went wrong
The platform contract was thinner than the interface
The cross-session profile leak was reproducible and initially looked broader than it was; later scoping put it in the per-organization pool, at medium severity. The session id being both the sole CDP credential and a logged value is also a poor boundary, especially when the id embeds an internal private IP.
The undocumented roughly 28-second sandbox execution cap poisons the exec path. It sits underneath the user-facing task, so a timeout can look like a flaky agent. The 8 ms claim also did not survive measurement: cold was 1930 ms and warm was 614 ms.
What I'd change
I would document the session, timeout, proxy, and timing contracts before building more convenience around them. I would also treat logs and credentials as one review surface: a value that authorizes a CDP connection should not be casually exposed through operational logging.
Links
The three public packages are linked above: solari-lab, solari-playtest and solari-ci. solari-browser-use is private, so it is not linked.