Launched this week
BrowserBash
CLI that turns plain-English into real browser tests
131 followers
CLI that turns plain-English into real browser tests
131 followers
Free, open-source CLI that turns one plain-English sentence into a real browser test — no selectors, no code, no flaky locators. Runs on free local models (Ollama) or free OpenRouter models, so there are zero API keys and no credit card. Works with local Chrome, LambdaTest, BrowserStack, Browserbase or any CDP endpoint. `npm install -g browserbash-cli` and automate any site in seconds. Apache-2.0.
OneUp
@promode_ Looks great and something I'd like to use, but my machine isn't powerful enough to drive local models. Can I use an AI subscription instead?
OneUp
@artk yes, you can use the openrouter, Groq.com APIs
@promode_ Love the landing page design and the copy! Very clear and neat.
OneUp
@zerotox Thanks Kumar
Looks awesome, can't wait to try this out! How does this differ from stagehand?
OneUp
@olli_paloviita @olli_paloviita honest answer: BrowserBash is built on Stagehand , it's the default engine 🙂
Stagehand (by Browserbase) is a TypeScript library you build with in code (act/extract/observe). BrowserBash is the batteries-included CLI layer on top:
• no code, a plain-English objective or a committable *_test.md file
• --agent → NDJSON + exit codes 0/1/2/3 for CI
• --record → video/screenshot/trace of every run
• one --provider flag: local Chrome, CDP, Browserbase, LambdaTest, BrowserStack
• Ollama-first, so it runs on free local models (no API keys)
• a local + cloud dashboard
Library to wire into your own code → Stagehand. Ready-to-run CLI/test-runner → BrowserBash (which uses Stagehand under the hood). Huge respect to the Browserbase team 🙏
Really interesting project! 🚀
The idea of describing a test instead of writing selectors is compelling, especially for quickly validating user flows.
I'm curious: if the UI changes significantly between releases, how does BrowserBash decide whether it's the same workflow with a different layout versus an actual regression that should fail the test?
OneUp
@prashant_patil14 There is Plan to keep a diff mechanism also, Visual Checks also
The hard part in plain-English browser tests is preserving intent after selectors change. A good test should explain the user-level invariant it protects, not just regenerate clicks.
OneUp
@krekeltronics
@patrick_krekelberg spot-on, that's the whole thesis. A BrowserBash objective is the user-level invariant, not a click path: you write "log in and verify the order shows 'Thank you for your order!'", and the agent re-derives the clicks each run. No selector is encoded anywhere, so a selector change can't touch the intent.
The honest caveat is that it's only as good as the invariant you write. "Click checkout" will drift; "verify the order is confirmed" protects intent. The tool nudges you toward asserting outcomes , every run returns a verdict against what you described but writing the right invariant is still on the author. Committable *_test.md files help there: the intent is reviewable in a PR, like code.
Love that it supports local models via Ollama right out of the box so we don't burn through API credits testing basic flows. Going to point this at my onboarding sequences today!
OneUp
@varunvivek Thank Vivek, You can always use cheaper model like Deepseek V4 Flash, Qwen3.5 models to automate scenarios, cost is very low.
https://browserbash.com/math.html
great man, how would you montize it if it is free
OneUp
@marc_vuit @marc_vuit great question 🙏 The CLI and local runs stay free forever, that's the open-source core, and I want it to stay that way. Monetization is opt-in: a paid tier for keeping your cloud run history + recordings past the free 15-day window. Free runs auto-expire after 15 days; if you want them retained, you upgrade. Team/hosted features are on the roadmap too. The free tier isn't a trick to upsell later it's the actual product.
We've gone from writing tests to describing tests. At this rate the browser is going to start filing bug reports against itself.
OneUp
@jacob_spencer2 😄 Honestly not far off, every run already returns a pass/fail verdict and a video recording of what it did, so the browser's basically halfway to filing its own incident report. "Describing tests" was the whole bet: say what done looks like, let the agent figure out the clicks. Thanks Jacob 🙏