Visual QA, fix, verify
The same page goes from broken to right, on screen
The product pages render broken. The agent looks at them in ego(lite), fixes the CSS in the source, and the open page re-renders correct on screen.
AI browser testing for your coding agent
Auto-run many browser tests in parallel with your AI agent
Playwright MCP drives the browser one tool call at a time: slow and heavy on tokens. Now Claude Code or Codex runs the whole test in ego(lite) with a few lines of code: 63% faster than agent-driven Playwright, and runs many tests in parallel, each in its own Space.
Download for Mac(yes, free)
Trusted by developers from
How to use, step by step
Web app testing in three steps: point your agent at localhost or any URL, say what to check, and read back what failed.
1
Download ego(lite)
A Chromium browser you use daily. One click imports your Chrome logins, so the agent tests as you.
2
Tell your AI agents what to check
Type /ego-browser and just say what to check, in any language your agent understands.
What should it test?
/ego-browser Open localhost:3000, go through checkout, and tell me what’s broken
3
Read back what failed
Each broken page comes back with the console error or failed request that explains it, not just a pass or fail.
| Page | Result |
|---|---|
| /checkout | OK |
| /product/gift-card | console error |
| /product/camera | image 404 |
Run browser tests just by asking
For example, I ask codex to check if the this e-commerce website has any bugs. Codex will run the whole test, fix all the bugs and tell me the result. The only thing I need to do scroll Tiktok and watch it work.
Run browser tests in lightning speed with ego(lite)
The old way to run browser tests is to use Playwright MCP or Chrome DevTools MCP, which runs one tool call at a time: each next step waits for the model to read the last result, slow and expensive. Now agents are able to run many steps in one pass of JS code with ego(lite), so it finishes faster and costs fewer tokens.
Across our 31-task benchmark on live sites, ego(lite) averaged 398 seconds per task against 648 for agent-driven Playwright (measured via playwright-cli).
The friction was never the browser. It was the layer in between
Across developer forums and issue trackers, complaints are most about the MCP, It’s the layer between your agent and the browser: the connection drops, the approvals pile up, the session breaks, the tokens balloon. ego(lite) has everything setup, so no more weird errors.
What you hit with Playwright MCP
The browser works. The connection to it doesn’t.
- Connection: the tools show up but the agent won’t call them, runs stall on “waiting for approval,” and the same server behaves differently in each client
- Approvals: a popup per tool call, often 10 to 30 in one task, even with “run everything” on
- Reliability: a task that half-finishes, or a navigation that already succeeded yet still times out
Fighting the layer before you test
ego(lite)
Nothing in between: ego(lite) is the browser itself
- Stable by design: the agent talks straight to a local browser it owns, with no MCP transport in the middle to drop or stall
- Fewer approvals: one pass runs many steps instead of one tool call per action
- Predictable: drop-in with any AI agent, the same way every time
Download then ask your agent to run the test
No test scripts. No selectors to maintain. Just say what to check
Playwright testing, Cypress testing, Selenium: you write the test, you own the selectors, and a class rename or a reshuffled layout breaks them. ego(lite) takes a plain-language check and locates elements by what they mean, so a UI change doesn’t break the test.
Writing Playwright / Cypress / Selenium
You write the spec, you maintain the selectors
- Hand-write and version a
.specfor every flow you want covered - Pin selectors like
page.click(".btn-x7f3")that break the next time the UI changes - Add waits and retries to fight flakiness yourself
- Build login automation or storage-state files to test behind a sign-in
- Re-run and repair the suite after every redesign
Tons of code to write, selectors to babysit
ego(lite)
Just say what to check
- No spec to write: tell your agent the check in one sentence
- Locates elements by their meaning, not a CSS class, so a rename or reshuffle doesn’t break it
- Smart waits handle async content, no hand-rolled sleeps
- Tests behind your sign-in with no login automation
- Need visual regression testing? The agent diffs the screenshots
Free. Just tell your agent what to check
For a versioned, headless suite that runs unattended in CI, or for testing across Firefox and WebKit, keep Playwright. ego(lite) is the fast, zero-script inner loop while you build.
How AI agents drive ego(lite)
The agent drives the browser by writing one complete JavaScript program. A single call bundles every step: open the store, add a product, wait for checkout, and runs them in sequence inside the browser, so the agent never waits for one action to return before sending the next.
Claude Code
>/ego-browser Open localhost:3000, add the first product to the cart, and check that checkout loads
●Bash(
ego-browser nodejs <<'EOF'
await openOrReuseTab('http://localhost:3000', { wait: true })
cliLog('opened localhost:3000 — storefront rendered')
await click('a[href^="/product/"]')
await waitForElement('button[data-testid="add-to-cart"]')
await click('button[data-testid="add-to-cart"]')
cliLog('added first product to cart')
await openOrReuseTab('http://localhost:3000/checkout', { wait: true })
await waitForElement('form#payment')
cliLog(`checkout loaded — ${(await pageInfo()).url}`)
EOF
)
⎿ Run ego-browser to walk the checkout flow
⎿Output:
[t=1240ms] opened localhost:3000 — storefront rendered
[t=2870ms] added first product to cart
[t=4480ms] checkout loaded — http://localhost:3000/checkout
Done. Checkout loads cleanly: storefront, add-to-cart, and the payment form all rendered.
─── 6s · ↑ 1.9k tokens · ego-browser runtime ───
It handles what usually makes browser tests flaky
We ran the scenarios developers say are hardest to automate. With ego(lite), agents handled all of them. Its semantic snapshot is generated inside the Chromium rendering engine itself, so it sees into shadow roots and cross-document iframes where injected scripts go blind.
Shadow DOM
Acts inside web-component shadow roots, where injected scripts go blind.
Payment iframes
Fills card fields inside cross-document iframes, like a Stripe checkout.
Custom date pickers
Picks a date range in a custom calendar with no test ids.
Drag and drop
Real HTML5 drag: moves a kanban card, the board follows.
Infinite scroll
Scrolls a lazy feed until every item is loaded, no hand-tuned waits.
Paginated tables
Walks every page of an admin table and pulls each row.
Conditional modals
Cookie banners and dialogs that pop up mid-flow get handled, not tripped over.
Autocomplete
Types an address, waits for the suggestions, picks the right one.
And a click that lands on a covered or disabled button is reported as a failure, not a false pass, the same way a real test framework treats it.
Your logged-in browser, still under your control
Letting an agent loose in the browser you’re signed in to is a fair thing to pause on. Here is where the boundaries are.
It works in its own Space
The agent runs in a separate workspace inside the browser. It shares your logins, but your tabs and windows stay untouched.
Every step is visible
A real, headed browser on your Mac, not a hidden headless process. Watch the run live, and interrupt it from your agent’s CLI at any point.
Nothing leaves your Mac
History, cookies, and sessions stay on your computer. ego(lite) doesn’t upload them.
And when a flow has real side effects, a checkout that charges or a delete that deletes, point the agent at localhost or staging, the same way you’d test it by hand.
Where ego(lite) fits, and where it doesn’t
Built for the fast inner loop: reproduce, debug, and verify while you develop.
What ego(lite) is great at
The inner loop, in a real browser.
- Reproduce and debug a bug in a real, logged-in browser
- Test flows behind a sign-in with no login automation
- Read console errors, failed requests, and page state
- Run exploratory checks across many pages in parallel
- Verify a fix in the same session you found the bug
When to reach for Playwright
Honest about the boundary.
- Headless regression suites that run unattended in CI (ego(lite) is a headed Mac browser)
- Testing across Firefox and WebKit (ego(lite) is Chromium)
- A versioned, deterministic test suite you commit and own
Related browser testing resources
Give your agent a real browser to test in
Download ego(lite) for free and give your AI agents a browser they can actually use.
FAQ
Do I need to write any test scripts or selectors?
No. You bring an AI agent you already use, such as Claude Code, Codex, or Cursor, and tell it what to check in plain language. The agent writes and runs the browser steps for you. There are no .spec files to maintain and no CSS selectors to hand-write, because ego(lite) locates elements from a semantic snapshot of the page.
How is this different from Playwright MCP?
Playwright MCP is an MCP server your agent drives one tool call per action, so a fifteen-step task means fifteen round trips to the model, which is slow and burns tokens. ego(lite) is the browser itself: the agent writes one short JavaScript pass that runs many steps at once, on your real logged-in browser. In our test on the same task in Claude Code with Opus 4.8, ego(lite) finished in about 18 seconds with 2 model round trips versus about 43 seconds and 9 round trips for Playwright MCP. It also runs many test tasks in parallel, each in its own Space, which a single MCP browser cannot.
Can it test pages behind a login?
Yes, when you choose a test account or browser context you are authorized to use. ego(lite) can test dashboards, internal admin panels, and account flows without first building a login script. If an OTP, CAPTCHA, passkey, consent, or other access-control challenge appears, the agent pauses for you; a real browser does not bypass the challenge.
How can tests run in parallel if it's my own browser?
Each task runs in its own Space, a separate workspace inside the same browser, like extra windows of the same profile. Spaces share your logins but keep their own pages, so parallel runs don't collide with each other or with the tabs you're working in. To a website it looks like one signed-in user with several tabs open. If your app allows only one active session per account, run those flows one at a time or use a test account.
Can it do visual regression testing?
Yes, in the sense that the agent captures a baseline screenshot and a new one, diffs them pixel by pixel, and tells you what changed and where. It is the agent doing the diff in your browser, not a separate visual-testing product to set up, so there is no Percy or Chromatic to wire in. For a managed baseline service with review workflows and CI gating, a dedicated visual-testing tool is still the better fit.
Can it run in CI as a headless regression suite?
Not today. ego(lite) is a real, headed browser on your Mac, built for testing while you develop: reproduce a bug, debug it, verify the fix, run checks across your pages. For a headless suite that runs unattended in CI, or for testing across Firefox and WebKit, keep your Playwright testing suite. ego(lite) is the fast inner loop, not the CI runner.
What can it actually catch?
Functional and runtime issues a real user would hit: a flow that breaks, a button that does nothing, an uncaught JavaScript error, a failed network request, a console error, a value that comes out wrong. The agent reads the page state plus the console and network, so it reports what failed and where, not just a green or red.
Is it safe to let an agent use my logged-in browser?
The agent works in its own Space, so your tabs and windows stay untouched, and everything happens in a real, visible browser window you can watch and interrupt from your agent's CLI at any time. Your browsing data stays on your own computer: ego(lite) doesn't upload your history, cookies, or sessions. For flows with real side effects, like a checkout that actually charges, point the agent at localhost or staging, the same way you'd test by hand. If you connect an external agent or model provider, that provider has its own data policy.
Can browser tests use DOM state instead of screenshots to reduce token cost?
Yes. Ask the agent to inspect the rendered DOM or accessibility state for routine assertions such as labels, URLs, values, and validation messages, and request screenshots only when visual evidence helps explain a failure. DOM evidence is compact and deterministic for many checks; it does not replace visual regression or layout review.
How should I handle a UI change that breaks a locator?
Capture the failing URL, visible text, screenshot, console output, and the expected behavior first. The agent can suggest a semantic or accessibility-based locator, but review that suggestion and rerun the original assertion. Do not accept a self-healed click merely because it turns the test green; it may have followed the wrong control.
Are agentic browser-testing tools ready for production?
They are useful for supervised, high-value checks in local or staging environments and for reproducing real user bugs. Keep deterministic unit, integration, accessibility, security, and headless browser suites in CI, and add explicit timeouts, fixtures, and blocked states before using an agent run as a release signal. Treat production actions as human-approved unless you have a safe sandbox.
How do I reset test data between AI browser-test runs?
Start each run from a known fixture: seed a staging account, use an idempotent setup endpoint, or reset the database through your normal test harness. Give each Space a distinct account or dataset when runs are parallel, and record the fixture ID in the report. Do not ask the agent to delete real customer data as a cleanup shortcut.
Can an AI agent validate a pull request in a real browser?
Yes. Start the PR's local preview or staging deployment, give the agent a short smoke-test brief, and require pass, fail, or blocked evidence for each assertion. This catches rendered and runtime issues that code review can miss, but it complements rather than replaces your normal CI and review gates.
Can I include WCAG 2.2 or axe checks in this workflow?
You can ask the agent to inspect headings, labels, focus behavior, contrast clues, and an axe or browser accessibility report exposed in the test environment. Use those results as triage and evidence, then run a maintained axe or equivalent CI integration and manual keyboard or screen-reader checks for a meaningful WCAG claim.