Local browser testing on your real Chrome before you open the PR
Kane CLI is local-first. Describe a flow in plain English and it drives the Chrome on your machine against localhost or any URL, with a headed browser you can watch and a verified pass or fail. Free to install.
or read the documentation
Why test in a local browser first
Code velocity outpaced verification. Your agent ships a feature in minutes, but confirming it works in a browser still means clicking through by hand or maintaining a brittle selector suite that rots with every layout change.
Local browser testing closes that inner loop. Kane CLI runs on the Chrome already on your machine, against localhost:3000 or any URL, so you verify the build you are editing right now, before it reaches CI or a teammate.
Describe the journey in plain English and watch the headed browser do it. Kane CLI checks each step against the rendered UI and returns a pass or fail. Local runs are free, and scale to the cloud with one flag.
What local browser testing with Kane CLI gives you
Local-first runs on real Chrome, against localhost or any URL, verified for a real user.
Runs on your local Chrome by default
Kane CLI is local-first. It launches the Chrome already installed on your machine and drives it directly over the DevTools Protocol, so there is no grid to provision, nothing to embed in your app, and every local run is free.
Test localhost and any URL
Point it at http://localhost:3000 or http://127.0.0.1:8080 and verify the build you are editing right now. Non-standard dev ports work without extra config, so the inner-loop check happens before you push.
Headed Chrome window you can watch
In the interactive TUI a real Chrome window opens and a step tree fills in as the agent reads the page, decides, and acts. Watching the local browser work makes a broken flow quick to locate.
Stateful local Chrome profiles
A fresh temp profile per run keeps state isolated. Need a signed-in session? Point a run at a named Chrome profile, log in once, and every later run reuses that session, with no repeated 2FA.
Plain-English flows on localhost
Describe the journey in natural language and Kane CLI checks each step against your locally rendered UI, returning a pass or fail tied to what a user on your dev build would actually see. No selectors to write.
Scale the same flow to the cloud
The objective you ran on local Chrome runs unchanged on the TestMu AI grid. Add --ws-endpoint to connect to a remote browser for a CI box with no Chrome, a specific OS, or geographic coverage. No rewrite.
Build up confidence before you push
Start in your terminal
Validate on the cloud
Release with confidence
Built for the inner loop
Kane CLI and KaneAI share the same automation engine and dashboard.
Start on the machine you build on
Kane CLI runs on the Chrome already installed where you write code. Nothing to provision, no grid to wait on, and local runs are free. Install it, aim it at localhost, and have a verified result in minutes.
See the local browser do the work
The headed window is part of the point. You watch the agent open your dev build, click, and assert in a real Chrome, so when a localhost flow breaks you see where on screen instead of decoding a stack trace.
Proof of every local run
Each run captures a video, a step trace, and a replay link. Drop that link into a PR or bug report so a teammate can see the exact local flow pass or fail without rebuilding your dev environment.
Run a local browser test in three steps
Install Kane CLI
Run npm install -g @testmuai/kane-cli and sign in with your TestMu AI account. It reuses the Chrome already on your machine, so there is nothing else to wire up.
Point it at your dev build
Use --url http://localhost:3000 for the build you are editing, or any deployed domain. A headed Chrome window opens so you can watch the run unfold on your own machine.
Describe the flow and check it
Type the journey in plain English: log in, submit the form, confirm the result. The agent walks your local Chrome through each step, checks it against the rendered page, and returns a pass or fail with a replay link.
Get Started With Kane CLI
🎉 Launch offer: Bonus credits for the first 3 months on paid plans
Choose the right plan for you
Local test authoring via CLI
Auto-heal & vision
View test cases on UI
Test Manager
Free
$0
/month
200 Credits
Resets in every
30 days
Starter
$19
/month
2000 Credits
Launch: 4,000 Credits (+100%)
Bonus for first 3 months
Pro
$99
/month
10,000 Credits
Launch: 15,000 Credits (+50%)
Bonus for first 3 months
Enterprise
Get access to solutions built on Enterprise-Grade Security, Privacy, and Compliances.
Need more credits?
Got a bigger use case in mind?
Let’s talk
Choose the right plan for you
Free
$0
/month
200 Credits
Resets in every
30 days
Starter
$19
/month
2000 Credits
Launch: 4,000 Credits (+100%)
Bonus for first 3 months
Pro
$99
/month
10,000 Credits
Launch: 15,000 Credits (+50%)
Bonus for first 3 months
Enterprise
Get access to solutions built on Enterprise-Grade Security, Privacy, and Compliances.
Need more credits?
Got a bigger use case in mind?
Let’s talk
Get the technical rundown
Documentation
Everything you need to install, configure, and run Kane CLI in under 2 minutes.
Frequently asked questions
Local browser testing means running your checks on a real browser on your own machine, before anything reaches a cloud grid or CI. With Kane CLI it is local-first by default: install the CLI, describe the journey in plain English, and it drives the Chrome already on your machine against localhost or any URL. You watch the headed window do exactly what a user would, and get a verified pass or fail in seconds. There are no selectors to maintain, and runs on your own Chrome cost nothing.
Yes. Point it at your dev server with --url http://localhost:3000 or http://127.0.0.1:8080 and Kane CLI opens it in your local Chrome. Non-standard ports work without extra setup, so you verify the build you are editing right now rather than a deployed copy. This is the inner-loop check: run it before the PR and catch the broken redirect or dead button while the change is still on your machine.
A headed run opens a visible Chrome window so you can watch the agent navigate, click, and assert in real time. That is the default in the interactive TUI, and it is the point: you see exactly what the agent sees, which makes a broken flow quick to pin down. A headless run uses the same local Chrome with no window, which is what you want in CI or when a coding agent drives it. Same engine and same objective, just add --headless when you do not need to watch.
Yes. By default each run uses a fresh, temporary Chrome profile so cookies and storage stay isolated. When a flow needs a signed-in session, switch to a named Chrome profile with kane-cli config chrome-profile. Run the login once, and every later run that selects the same profile inherits that session, so saved addresses, extensions, and auth persist without re-entering 2FA each time.
Yes, with one flag. The objective you ran on your local Chrome is identical to the one you run on the TestMu AI grid. Pass --ws-endpoint (or --cdp-endpoint) and Kane CLI skips the local launch and connects to a remote browser instead, for a CI image with no Chrome installed, a specific OS or browser version, or geographic coverage. Start local and free, then scale to the grid without rewriting a single line.
The CLI is free to install, and every run on your own local Chrome is free. The free tier starts with 100 credits and no signup friction. Only cloud runs on the TestMu AI grid draw against your plan. So the whole inner loop, from localhost to a verified end-to-end pass, stays free, and you reach for the grid only when you need scale or coverage one machine cannot give you.
Teach your agent to test in a local browser
Point your coding agent at the Kane CLI guide and it will install, authenticate, and verify your flows in a real local Chrome on its own, before it ever calls a feature done.
Point your agent to: testmuai.com/kane-cli/agents.md