The vendor pages all promise fast sessions, and each measures fast its own way. A teammate drops a latency chart into the evaluation doc, someone else adds a chart from a different vendor, and neither timed the same steps from the same machine.
The way out is a single test, run the same way against every vendor. Steel maintains that test as an open-source benchmark, and Solari's results sit in a pull request that is still open: 199.9 ms average end to end across 5,000 runs, about 4x faster than Kernel, about 4.5x faster than Steel and about 14.8x faster than Browserbase. This guide covers what the benchmark times, where the time goes, what each vendor charges and how to rerun it.
What the Benchmark Measures
A benchmark is only as useful as the steps it times, so the method comes first. Each run creates a session through the vendor's API, connects Playwright with connectOverCDP, opens a page and waits for the DOMContentLoaded event, then releases the session. The same runner drives every vendor with no provider-specific tuning.
Results come out as averages, medians and percentile figures for each step and for the whole loop. That loop is what an agent pays every time it opens a fresh headless browser, so speed is the first column, and price is the next.
The Four Vendors at a Glance
The table sets the four side by side on fit, hourly price and the free starting point.

Solari bills $0.05 per browser hour on the Team plan, and the Free plan includes $3 of monthly credits. At list price, that rate is about 2x cheaper than Browserbase and about 1.6x cheaper than Steel per browser hour.
Steel's Scale plan bills $0.08 per browser hour on top of $250 a month, and its free Launch plan starts with a $30 one-time credit. Browserbase's Startup plan costs $99 a month with 500 browser hours, then $0.10 per browser hour, and its Free plan includes 1 browser hour. Kernel bills its headless browsers at $0.0000166667 per second, and its free Developer plan includes $5 of monthly credits.
An hourly rate matters most when the per-session overhead is small, which is what the step breakdown shows.
Where Solari's Time Goes
The total hides which step costs what, so the benchmark also reports each step on its own. The chart shows Solari's medians.

Solari creates a session in a median of 8 ms and releases it in 2 ms, so the two control-plane steps a vendor owns barely register. The CDP connect takes 24 ms, while the page load takes 155 ms and is most of the run, and that step depends on the website and the network as much as on the vendor.
For an agent that opens a fresh browser per task, the vendor's overhead nearly disappears and the website becomes the slow part. The Solari sessions guide shows the create, connect and release calls the benchmark exercises. Speed still sits next to fit, so each vendor's niche comes next.
Where Each Vendor Fits
The four vendors split along different lines, so each entry below covers what the vendor is built for and the trade-off that comes with it.
Solari. Solari is built for fleets that open many short sessions, where start time and the hourly rate both multiply with volume. Browsers, sandboxes and desktops run from one account and one API, and profiles keep a login between runs. Teams on Browserbase can move by changing the import and the key, though the lowest rates sit on the larger plans, so a small fleet starts at a higher hourly rate.
Steel. Steel's browser is open source and can be self-hosted, which suits a team that wants the same browser on its own machines and in the cloud. Its Scale plan allows 100 concurrent sessions of up to 1 hour each, but its stealth browser is included on Enterprise only, so a pipeline facing sites that block automation may need a custom contract early.
Browserbase. Browserbase sells search, fetch and agent runs next to its browsers, so a team that wants those on one invoice gets them from one vendor. Its Startup plan allows 100 concurrent browsers, and like its other plans it is priced around included hours and API allowances, so a browser-only fleet pays for allowances it may not use.
Kernel. Kernel bills active runtime only: a browser enters Standby Mode 5 seconds after its last CDP or Live View activity and stops accruing usage cost. That suits agents that sit idle between steps, although headless, headful and GPU browsers bill at separate per-second rates, so a forecast depends on the mix a fleet runs.
Every trade-off above is worth testing on real traffic, starting with the benchmark itself.
How to Rerun the Benchmark
A number measured on somebody else's machine is a starting point, so the benchmark is built to be rerun. Clone the repository from the pull request above, check out the branch that adds the Solari provider, set an API key for each vendor, and run the README's commands:
Add Solari to the provider list, and the runner writes a results file per vendor. The README's sample results and the Solari pull request ran from different AWS regions, so the fairest comparison runs all four from the region your agents use. The runner also times only the first navigation, while real agents do far more per session.
Choosing the Right Setup
On a shared benchmark, the choice comes down to what a fleet does most. Steel suits a team that wants to self-host its browser, Browserbase a team that wants search and fetch bundled, and Kernel agents that idle between steps. When session start time and the browser-hour bill decide, Solari leads all three, and the Solari launch overview explains how sandboxes and desktops share the account. 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 benchmark from your own region, then point an existing Playwright script at a Solari session for a day of normal traffic. Solari is the fastest and cheapest of the four for that job, at the 199.9 ms average and the Team rate above, and the Free plan needs no contract. Create a free Solari account and run the comparison on your own workload.
