How it works
Hands, eyes, and the log
Six facts about the thing you are buying.
Driven over MCP
The browser publishes its own tools, so an agent in your editor or terminal drives it directly. There is no driver binary to match to a browser version and no script to keep in sync.
Real input, real profile
Clicks and keystrokes arrive from the operating system, in the browser your users actually have. Native dialogs, file pickers and anything that checks whether input came from a person behave the way they do for a person.
Console, network, DOM
The agent reads the console log, the failing request and the DOM in the same session it just acted in, so a generic error message still ends with a cause.
Sees the screen
A screenshot and the accessibility tree come back on request, so a check survives a markup change that would break a brittle selector.
Three kinds of machine
The same agent drives this PC, a Windows machine you own over a remote connection, or a VirtualBox or Hyper-V guest it creates for one run.
Platform
Windows 10 and Windows 11, on a Chromium engine. macOS and Linux are not supported.
Where the check runs
“Works on my machine” is testable when the agent can reach the other machines too. This is also the unit a plan is counted in.
This PC
The machine you are working on. The browser is already installed and signed in, so a check runs against the state you actually have.
Counts as one machine
A machine you own
Connect to another Windows PC on your network or over the internet and drive it from the same window — the staging box, the build agent, the one machine where it fails.
Counts as one machine
A fresh guest
Have the browser create a VirtualBox or Hyper-V guest, run the check in it, and take it away afterwards. First-run behaviour is testable because nothing is left over.
Counts as one machine
What this is not
So you can tell in a minute whether it belongs in your stack.
- It is not a test runner. There is no assertion language, no fixtures and no JUnit report — the agent runs the check and tells you what it found.
- There is no CI integration yet. A run starts from your machine or from a schedule on it, not from a pipeline.
- One engine, one platform. Chromium on Windows. There is no Safari, no Firefox and no mobile device farm.
Plans
A plan is the number of machines an agent may drive at the same time. The browser itself is free.
STARTER
$19/mo
- 10 machines under test
- Console, network and DOM capture
- The agent clicks by looking at the screen
SCALE
From $199/mo
- Everything in Pro
- 10+ concurrent sign-ins
- 100+ machines under test
Questions people ask first
How is this different from Playwright?
Playwright drives a browser built for automation, over its debugging protocol, from a script you maintain. This drives the browser your users have, with input that comes from the operating system, from an agent that reads the result. The two are not rivals — this is for the checks that fail because the environment is real.
Which MCP clients work?
Any client that speaks the Model Context Protocol. The browser publishes its tools and the client lists them; nothing is specific to one vendor.
What counts as a machine?
This PC, a Windows machine you connect to remotely, and a virtual guest each count as one. A plan is the number of machines an agent may drive at the same time.
Does a schedule run when the browser is closed?
No. Schedules fire from the browser on your own machine, so it has to be running in the tray. Nothing is executed on our servers while you are away.
Does one subscription cover your other products?
The account does. Browser, Social and Editor are billed separately.