Test and scripting frameworks

BrowserOS neo vs Playwright

Your suite proves the paths someone wrote down. neo runs the checks that never justified one.

Playwright drives Chromium, Firefox and WebKit from a script you write in TypeScript, Python, Java or .NET. It is the best end-to-end test framework there is, and Microsoft now points it at agents too, through a CLI and an official MCP server.

BrowserOS neo is a browser. You install it, import your Chrome logins in one click, and any agent that speaks MCP opens tabs in it while you watch. It is not a test runner and never will be.

[ 01 ]

The short version

Choose BrowserOS neo when

The task is an errand, not something you want to commit to a repository.
It happens inside accounts you are signed into, and you want that by default.
You want to watch it happen, and replay it when it goes wrong.
You would rather install an app than assemble a setup.

Choose Playwright when

The check must run on every commit, in CI, with nobody watching.
You need Firefox and WebKit, or SDKs in four languages.
The run must fail the moment the page changes, because that is the signal.
The behaviour matters enough to be worth maintaining as code.

[ 02 ]

Side by side

BrowserOS neo compared with Playwright, row by row.
Dimension	BrowserOS neo	Playwright
What it is	BrowserOS neoA browser you install, sign into, and hand to your agent over MCP.	PlaywrightA framework you write code against, in TypeScript, Python, Java or .NET.
Describing the work	BrowserOS neoYou tell the agent what you want, in plain language.	PlaywrightYou write the steps as a script, and keep it working as the site changes.
Logged-in sites	BrowserOS neoOne-click import of your Chrome logins, into a browser that runs beside your main one.	PlaywrightTest contexts start blank; you script the login once into a storageState file. Playwright MCP differs: persistent profile by default, plus an extension that attaches to tabs you are already signed into.
When a page changes	BrowserOS neoThe agent re-reads the page and adapts. It usually copes, and sometimes gets it wrong.	PlaywrightThe locator breaks and the run fails. For a test that is correct behaviour, not a flaw.
Several at once	BrowserOS neoSeveral agents share one visible browser, each with its own tabs.	PlaywrightWorkers, shards and parallel contexts, usually headless, built for throughput.
Continuous integration	BrowserOS neoNot built for it. This is interactive work on your own machine.	PlaywrightBest in class. Retries, sharding, reporters, first-party CI docs.
Browser engines	BrowserOS neoChromium only.	PlaywrightChromium, Firefox and WebKit.
Seeing what happened	BrowserOS neoWatch live, then replay the session as a scrubbable video. On by default.	PlaywrightHeaded runs and UI Mode show it live; Trace Viewer replays a run with DOM snapshots, network and console — a deeper technical record than ours.
Price	BrowserOS neoFree. You bring your own model keys.	PlaywrightFree. Agent use still costs model tokens.

The row worth pausing on is what happens when a page changes. Playwright fails, correctly, because a test exists to notice exactly that.

Exploratory work wants the opposite. When you are reproducing a ticket or sweeping a build, a run that stops at the first moved button tells you nothing. You want it to reach the end and show you what it found, and that is the half of QA your suite was never going to cover.

[ 03 ]

Your suite covers the paths someone wrote down.

Every test you have is a path somebody decided was worth the cost of writing. The rest of the QA week is not like that. Reproducing a ticket, sweeping a staging build before release, confirming a fix behind SSO, chasing something a customer saw once: all done by hand, because a test for it would cost more than doing it.

neo runs that work as tests without turning it into test code. Describe the case in plain language, the agent carries it out in a browser already signed in to your environments, and the session replays afterwards, so a reproduction is a recording rather than a paragraph of steps.

It is not a CI gate and it does not touch your suite. It covers the much larger pile of checks that were never going to become one.

[ 04 ]

Common questions

Can I use BrowserOS neo for QA?

Yes, and it is the main case for it. Describe a check in plain language and the agent carries it out in a browser already signed in to staging. Every run is recorded, so what you attach to a ticket is a replay rather than a written list of steps.

Does BrowserOS neo replace Playwright?

No, and it is not trying to. Your suite covers the paths that earned automation and runs them on every commit. neo covers the exploratory passes, bug reproductions and pre-release sweeps around it, which on most teams is the larger half of the work.

How do I reproduce a bug with BrowserOS neo?

Give the agent the steps from the ticket. It attempts them in a browser holding your real sessions, and the session replays afterwards, so the reproduction is a recording either way: proof when it reproduces, and evidence of what was tried when it does not.

Can Playwright use my existing Chrome logins?

It depends which part. Test contexts are isolated on purpose, and the documented pattern is to script the login once into a storageState file. Playwright MCP keeps a persistent profile and its extension can connect to existing tabs. neo differs mainly in the default: the logins are already there.

[ 05 ]

Check it yourself

Every claim about Playwright here was read off these pages on 4 August 2026. If something has gone stale, tell us.

What we could not confirm

We did not set up the Playwright MCP browser extension ourselves; that claim comes from its documentation.

[ 06 ]

Other comparisons

Give your agent a browser it can sign into.

Free, open source, and it sits beside the browser you already use.