Solari vs Kernel: How to Migrate, Speed and Cost

In 2026, browser agents are production software, and investors now call web AI agents the next frontier of automation. The cloud browser under an agent has become infrastructure, and teams switch browser vendors for the same reasons they switch any other vendor: speed and cost.

For teams on Kernel, a move to Solari changes three things: the calls that open and close a browser, the proxy options and where logins live, while the Playwright code that drives each page carries over. Solari is about 4x faster than Kernel on Steel's open-source benchmark (5,000 runs; the pull request is open for anyone to rerun) and about 3.6x cheaper per browser hour at list price.

Why Does the Browser Vendor Matter More in 2026?

The browser vendor matters more because agents now open browsers all day, so start time and hourly price are paid again on every task. A year ago most teams picked a vendor once, for a prototype, and rarely looked again.

Today an agent in production opens a fresh session for each job, runs it and closes it. A slow start or a high hourly rate is no longer a one-off cost; it repeats thousands of times a week.

Agents also do more than browse. Many now write and run code, or operate desktop apps through computer use, which adds a second and third vendor to the stack unless one account covers all three. That is why the switch is worth planning: the edits are small, and the payback starts with the first session.

What Changes When You Move From Kernel?

Only the lines that name the vendor change; the code between them is ordinary Playwright. The figure below pairs each of those lines with its Solari equivalent.

Kernel's browsers.create() returns a session_id and a cdp_ws_url, which a script hands to Playwright's connectOverCDP. A Kernel browser with no client attached enters standby after 5 seconds, with billing paused, and is deleted when a configurable timeout runs out. On Solari, browser.close() ends the session outright, so the code that opens and closes the browser is your first edit.

How Do You Migrate From Kernel to Solari?

You migrate in six short steps, and your existing test suite can run after the first one. A typical Kernel script creates a browser, connects Playwright and deletes the browser at the end:

import Kernel from "@onkernel/sdk"
import { chromium } from "playwright"

const kernel = new Kernel()
const kb = await kernel.browsers.create()
const browser = await chromium.connectOverCDP(kb.cdp_ws_url)
const page = await browser.contexts()[0].newPage()
// existing Playwright code
await kernel.browsers.deleteByID(kb.session_id)

import Kernel from "@onkernel/sdk"
import { chromium } from "playwright"

const kernel = new Kernel()
const kb = await kernel.browsers.create()
const browser = await chromium.connectOverCDP(kb.cdp_ws_url)
const page = await browser.contexts()[0].newPage()
// existing Playwright code
await kernel.browsers.deleteByID(kb.session_id)

import Kernel from "@onkernel/sdk"
import { chromium } from "playwright"

const kernel = new Kernel()
const kb = await kernel.browsers.create()
const browser = await chromium.connectOverCDP(kb.cdp_ws_url)
const page = await browser.contexts()[0].newPage()
// existing Playwright code
await kernel.browsers.deleteByID(kb.session_id)

On Solari, launch() opens the browser and connects in one call, and the SDK ships its own matching Playwright client, so there is no second package to keep in step:

import { Solari } from "@solarisdk/browser"

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const browser = await solari.launch()
const page = await browser.newPage()
// existing Playwright code
await browser.close()

import { Solari } from "@solarisdk/browser"

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const browser = await solari.launch()
const page = await browser.newPage()
// existing Playwright code
await browser.close()

import { Solari } from "@solarisdk/browser"

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const browser = await solari.launch()
const page = await browser.newPage()
// existing Playwright code
await browser.close()

• Swap the session calls. Replace create, connect and delete with launch() and close(), as above. close() shuts the browser down and cleans up in one step, so it is safe to call from a finally block. Run your tests as soon as this compiles.

• Keep your own CDP client if you prefer. If your agent uses playwright-core, Puppeteer or another client that speaks the Chrome DevTools Protocol, call sessions.create(), connect to its cdpEndpoint and end the session with releaseAndWait(). That endpoint carries the session's signed id and works as a credential, so keep it out of logs.

• Map stealth and proxies. Kernel creates proxy configurations once and attaches them by proxy_id; Solari takes the proxy as a session option, such as proxy: { country: "us", tier: "static" }. A Kernel ISP configuration maps to the static tier and a residential one to the default. Proxies need stealth turned on and a paid account; a free account gets a 402.

• Move logins into profiles. Kernel profiles capture the browser's whole Chromium data directory, including open tabs and preferences. A Solari profile holds Playwright's storage state: the cookies and per-origin localStorage a site checks to decide who is signed in. Export it by attaching the Kernel profile, calling context.storageState() and uploading the JSON with profiles.save(), or sign in by hand in the profile editor for accounts behind two-factor prompts.

• Use the seeded context. A Solari profile seeds the session's default context only, and browser.contexts()[0] is not guaranteed to be that context. Replace that Kernel habit with browser.newPage() or session.context, and your agent opens already signed in.

• Review recording. Recording on Solari is an opt-in flag, and it captures input values by default. Leave it off for any session that types a password, and turn it on elsewhere so you can replay what the agent did.

What Role Does Solari Play?

Solari is the infrastructure your agent runs on: cloud browsers, sandboxes and desktops from one API. Your agent brings the logic; Solari gives it a fast, isolated place to work.

• Sessions that start at once. Solari browsers are ready in 8 ms, so an agent that opens a fresh session per task spends its time on the task. Short jobs gain the most, because start time is a larger share of each run.

• A whole fleet in one pass. With Solari you can launch up to 100,000 browser sessions at once, so you can run a full list of tasks in parallel instead of queuing them. A job that ran overnight finishes in one pass.

• Logins that stay signed in. Profiles reopen the same cookies on every later session, and auto-login signs your agent in through 1Password when a site asks again. Your agent never sees the password.

• Sites that block automation. Turn on stealth for the sites that need it, route traffic through a proxy and let Solari solve CAPTCHAs such as reCaptcha, hCaptcha and Turnstile. Every other site runs on the faster default browser.

• Bring the agent you have. Solari works with Playwright, Puppeteer and any CDP client, so your page logic moves over unchanged. The migration touches the session code, not the agent.

Browsers are only part of the job. Solari sandboxes run the code your agent writes, and Solari desktops operate apps that have no API, all on one account and one bill: one API for browsers, sandboxes and desktops.

What Does the Switch Do to Speed and Cost?

The speed gain pays back on every session your agent opens, and the price gap on every hour it runs. Agents that start many short sessions a day gain the most from the first; busy, long-running browsers gain the most from the second.

Both vendors charge the same monthly fee at the middle tier, but they bill usage differently. Solari returns the whole fee as usage and charges a flat hourly rate per browser. Kernel returns part of the fee as credits and bills by memory per second, so its hourly cost rises with the size of the browser you run.

Kernel's standby mode stops billing for idle browsers, which helps agents that sit waiting between steps. The gap is widest for browsers that stay busy.

Solari or Kernel: Which Should You Choose?

Choose Solari when session start time and a predictable hourly rate matter, or when the same agent also needs sandboxes and desktops under one account. Stay on Kernel when your agents depend on its Managed Auth and browser pools. Kernel is the more established browser platform; Solari is the younger company and moves faster on speed and price.

Where Are Browser Agents Going Next?

Over the next year, the browser layer under agents changes in four ways:

• Vendors measured in the open. Buyers will expect benchmarks they can rerun against named peers, not numbers from a vendor's own lab.

• One account for every surface. Agents that browse, run code and operate desktops will run on one platform instead of three vendors stitched together.

• Logins handled by the platform. Password managers and saved profiles will sign agents in, so credentials never pass through a prompt.

• Agents that use any app. Models with computer use already operate software through a screen, so agents will work inside tools that never shipped an API.

What stays human is judgement: which sites an agent may act on, what it may do under your name, and who reviews the replay when something looks wrong. The teams that win will spend their people on those calls and hand the rest to agents.

Get Started With Solari

Start by porting one script: install @solarisdk/browser, swap the create, connect and delete calls for launch() and close(), and run your existing tests against it. Solari is the fastest and cheapest way to run cloud browsers and VMs for browser agents. Get started with a free account and start running your agents today.