In 2026, the teams that run browser agents in production build their own agents: the planner, the prompts and the Playwright code belong to the team, and the browser underneath is infrastructure it rents. Once the agent logic lives in-house, a browser vendor that bundles its own agent and bills per finished task stops matching how the work gets done.
That is when teams move their browser agents from Anchor Browser to Solari. The move is small: your Playwright code stays as written, and the edits land on how a session opens and closes, a few option names, recording and where saved logins live. Solari is about 40x faster than Anchor end to end on Steel's open-source benchmark and bills browser time by the hour. This guide covers each edit in the order a migration meets them, then what the switch does to speed and cost.
Why Are Teams Moving Browser Agents Off Anchor?
Teams move when the agent is their own and the browser is the only part they still buy. Anchor is built around tasks described in plain language: its SDK runs agentTask() on a sentence such as "go to news.ycombinator.com and get the title of the first story" and returns the result.
That suits a team that wants the vendor's agent. A team with its own planner calls Playwright directly, and for that team the measures that count are how fast a session opens, how many run at once and what an hour of browser time costs.
Anchor counts credits per completed task; Solari counts browser time. The rest of this guide shows what changes in your code when you make that switch.
What Changes When You Leave Anchor Browser?
Only the lines of an Anchor script that name the vendor change; everything between them is standard Playwright. The figure lines them up against their Solari equivalents.

The work comes down to five edits:
Swap the session calls. Anchor's createSession() plus connectOverCDP becomes one launch() call on Solari. Your existing tests can run as soon as the first session opens.
Drop the cleanup code. On Solari, browser.close() ends the session and cleans up. Code that ended Anchor sessions in a separate step can go.
Flatten the options. Proxy and CAPTCHA settings move from Anchor's nested request body to flat options on launch(). Both need stealth turned on.
Turn recording on where you read replays. Anchor records by default; Solari records only when you ask. A pipeline that reviews sessions adds one flag.
Move saved logins into profiles. Export each login with Playwright and upload it to a Solari profile. Your agent then starts every session already signed in.
How Do You Swap the Session Calls?
You replace createSession() and connectOverCDP with launch(), and keep the Playwright code in between. An Anchor session starts with Sessions.createSession(), which returns a cdp_url that Playwright's connectOverCDP attaches to:
On Solari, create and connect collapse into launch(), and browser.close() shuts the browser down and cleans up, so it is safe to call from a finally block:
Anchor's SDK quick start marks closing a browser made with createBrowser() as a disconnect while the session keeps running, so some Anchor scripts end sessions elsewhere. On Solari that step can go.
If you would rather keep your own client, call sessions.create(), connect playwright-core to its cdpEndpoint and finish with releaseAndWait(). Any client that speaks the Chrome DevTools Protocol connects the same way.
How Do You Map Proxies, CAPTCHA and Recording?
Proxy and CAPTCHA become flat options on launch(), both behind stealth, and recording becomes a flag you set. Anchor nests them in the request body, with session.proxy.active for a proxy and browser.captcha_solver.active for CAPTCHA solving. On Solari, turn on stealth and pass the rest beside it:
proxy: "us" routes traffic through a rotating residential IP, and the object form lets you pick a static ISP or mobile IP and sticky sessions. Stealth, proxies and CAPTCHA solving need a paid plan, so run your first stealth test on a paid account.
Recording is the option whose default flips. Anchor's recording page says it records sessions automatically as MP4 video, while every Solari option is opt-in. Add the recording option wherever a pipeline reads replays.
The Solari replay is a line-by-line log that captures input values by default. A session that types a password should run unrecorded.
How Do You Carry Logins Over With Profiles?
Export each login with Playwright and upload it to a Solari profile. Anchor keeps logins in browser profiles passed by name, or in identities that sign in before each session.
A Solari profile saves cookies and per-origin localStorage in Playwright's storageState format, and a session started with its profileId begins signed in.
At the end of a signed-in run on Anchor, call context.storageState() and write the JSON to disk. Then create a Solari profile and upload the file with profiles.save(). For sites with two-factor prompts, sign in by hand in the console's profile editor instead.
One rule trips migrations up. A profile seeds only the session's default context, and browser.contexts()[0] is not guaranteed to be that context. Replace the Anchor habit of reaching for the first context with browser.newPage() or session.context.
What Does the Switch Do to Speed and Cost?
Solari opens sessions faster and bills browser time by the hour instead of per task. In the run cited above, Solari averaged 199.9 ms end to end across 5,000 runs, and its pull request is open for anyone to rerun. An agent that opens many short sessions pays the start-up cost on every job, so the gap grows with the size of your fleet.
Price is counted differently on each side. Anchor's pricing charges 0.1 credits per completed task, from Starter at $50 a month for up to 25 concurrent browsers to Growth at $2,000 a month for up to 200.
Solari bills browser time by the hour, from Starter at $20 a month and $0.10 per browser hour to Professional at $200 a month and $0.07 per browser hour for 150 concurrent browsers. If your fleet needs that many browsers open at once, compare Solari Professional with Anchor Growth.
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 place to work at production scale.
A whole queue in one pass. Solari supports up to 100,000 concurrent browsers, so you can run every task in a queue at once instead of working through it overnight. Each session starts clean unless you attach a profile.
The client you already use. Solari works with Playwright and any client that speaks the DevTools Protocol. Moving an existing agent changes how a session opens, not the code that drives the page.
Sites that block automation. Stealth, proxies and CAPTCHA solving switch on per session, so only the sites that need them use them. Every other site runs on the default browser, which is the fastest to start.
A record of what the agent did. A recorded session replays in the console or downloads as a log, so whoever reviews the agent's work sees exactly what it saw. Restrict who can read replays that touched sensitive input.
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, as Introducing Solari sets out.
Anchor is the broader bundle for managed web tasks; Solari is the younger, focused infrastructure company and moves faster on speed and price. Choose Solari when the agent logic is already yours and session speed, hourly billing and concurrency drive the decision. Stay with Anchor when plain-language tasks and managed identities are why you picked it.
What Comes Next for Browser Agents?
Over the next year, browser agents change in four ways:
Shorter, more frequent sessions. Agents will open a fresh browser for each step instead of holding one open for a whole job, so session start time becomes part of every task.
Logins handled like credentials. Saved logins will be stored, rotated and re-signed by a person when a site asks again, while the agent keeps running.
Browsers next to code. Agents will pair a browser with a sandbox, reading a page in one and processing what they found in the other.
Screens as well as pages. Models with computer use will operate desktop apps through a screen, so agents will need full desktops alongside browsers.
What stays human is judgment: which accounts an agent may sign in to, what it may do under your name, and what to change when a replay shows something wrong. The teams that move fastest spend their people on those calls and leave the sessions to infrastructure.
Get Started With Solari
Start by porting one script: install @solarisdk/browser, swap createSession() and connectOverCDP for launch(), 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.
