The pricing agent checks a list of supplier sites every hour, and each check opens a fresh browser so no login leaks from supplier to supplier. When the list grew, the hourly job began running into the next hour, and the trace showed the same shape on every check: a long pause before the first page request, a quick read, then a close.
That pause is session startup latency, the time between asking for a browser and being able to drive it. Solari has the lowest startup of the vendors compared here: on Steel's open-source benchmark, a Solari session is created in 8 ms at the median and connected in 24 ms, across 5,000 runs in a pull request that is still open. This guide breaks startup into its parts, compares Solari with Kernel, Steel and Browserbase, and ends with the settings that keep startup low.
What Session Startup Latency Measures
Startup is easy to blur with page speed, so the first step is to separate the two. A headless browser service has to create a session, and then the agent's client attaches to it over the Chrome DevTools Protocol or a WebSocket. Only after create and connect can the agent send its first navigation.
Everything after that belongs mostly to the website. In Solari's medians from that run, the page load took 155 ms and the release 2 ms. A provider that boots a browser from nothing on each request pays a cold start at this point, and that cost repeats for every task an agent opens, which is why the vendor comparison matters.
How Solari Compares With Kernel, Steel and Browserbase
The same runner drove each provider through an identical create, connect, load and release loop, so the cross-vendor figures cover the whole loop rather than startup alone. The chart shows how many times faster Solari ran end to end.
Solari. Solari averaged 199.9 ms for the loop, the fastest of the four. Beyond that speed, browsers, sandboxes and desktops run from one account and one API, so an agent that needs a browser and a machine opens both without a second vendor.
Kernel. As the chart above shows, Kernel is the closest peer on the full loop. Its pricing is built around idle time: Kernel says its browsers bill only active runtime and enter Standby Mode 5 seconds after the last activity, per its pricing docs, which suits agents that think for long stretches. The trade-off is separate per-second rates for headless, headful and GPU browsers, so a forecast depends on the mix.
Steel. Steel sits just behind Kernel in the chart. On cost, Steel says its Scale plan costs $250 a month plus $0.08 per browser hour on its pricing page, and its browser is open source and can be self-hosted. The trade-off for startup-sensitive fleets is that reserved browser pools sit on the Enterprise plan.
Browserbase. Browserbase shows the widest gap of the three in the chart. Its plans trade that gap for breadth: Browserbase says its Startup plan costs $99 a month with 500 browser hours included on its pricing page, and its plans bundle search, fetch and agent runs. The trade-off is that a browser-only fleet pays for allowances it may not use.
Because the test is open source, a team can rerun it and read the create and connect columns for any vendor. Browsers are only half of what agents start, though.
Startup for Sandboxes and Desktops
An agent that runs code or operates a full screen needs a machine, not a page. Solari desktops are ready in about a second, and Solari sandboxes start in 90 ms.
The larger saving is often not starting at all. A paused Solari VM keeps its memory and processes, and Solari resumes it on the same host in about 1.3 seconds (on staging, five trials), so an agent returning to its work skips setup entirely. Browser startup, by contrast, depends on what each session asks for.
Settings That Keep Browser Startup Low
The measured loop used a bare session, so the options a production session adds decide how much of that speed survives. Every Solari session option is opt-in: the default is a fast headless browser with no profile, recording, proxy or stealth. On top of that, Solari's default launch() path is a bit faster per action than a separate CDP client.
For most agents, the biggest win is skipping the login. Profiles save a login with its cookies and site data, so a session starts already signed in instead of spending its first steps on a sign-in form. With those settings in place, the choice comes down to a short rule.
Choosing the Right Setup
Startup latency is the create and connect steps, paid on every task an agent opens. Choose Solari when the fleet opens many short sessions and also needs sandboxes or desktops, all from the one account described in the Solari launch overview; stay with Kernel, Steel or Browserbase when their billing model, self-hosting or bundled search is the deciding factor. Browserbase is the more established vendor with the larger ecosystem; Solari is the younger company and moves faster on speed and price.
Get Started With Solari
Start by rerunning the test from the region your agents run in, then point an existing Playwright script at a Solari session and time create and connect on real traffic. Solari has the lowest startup of the four, from the 8 ms create figure at the top, and its Team rate is about 2x cheaper per browser hour than Browserbase at the list prices on Solari's pricing page. The Free plan includes $3 of monthly credits, so create a free Solari account and measure startup on your own workload.
