Every time I've needed to automate a browser, I've paid what I call the Selenium tax.
You want to click a button on a page. Simple. But first: install the bindings, match the driver version to your browser version, watch it break after a browser update, add waits because everything is flaky, and write 40 lines of setup code before you do the one thing you actually wanted.
For a lot of jobs, that's overkill. Sometimes you just want to tell a browser: go here, click this, give me that text. And you want to do it from a shell script, or from an AI agent, or from any language that can make an HTTP request, without installing a whole automation framework.
So I built a small Chromium-based browser with a local REST API. You start it, and it listens on a port on your own machine. Everything the browser can do (navigate, click, type, read pages, pull out structured data) is an HTTP endpoint.
Here's what driving it looks like. Create a session:
curl -X POST http://localhost:9090/v1/session
Go somewhere:
curl -X POST http://localhost:9090/v1/session/s_1/go \
-d '{"url": "https://example.com"}'
Click a button and read what's on the page:
curl -X POST "http://localhost:9090/v1/act?session=s_1" \
-d '{"do": [{"type": "click", "id": "submit-btn"}]}'
That's it. No drivers. No bindings. No SDK. If your tool can make an HTTP request, it can drive a browser.
Why HTTP and not another library
Two reasons.
First, agents. I build AI agents, and agents are terrible at managing Selenium sessions: versions drift, processes leak, and the whole thing falls over at 2 AM. An HTTP API is something an agent can actually use reliably: stateless requests, JSON in, JSON out.
Second, universality. Python, Node, Rust, bash, PowerShell: everything speaks HTTP. A library locks you into one ecosystem. An endpoint doesn't.
The browser itself stays open with your tabs and your logged-in profile while you drive it. You're not automating a headless ghost. It's a real browser you can also just look at.
What it's not
It's not trying to replace Playwright. If you need cross-browser testing matrices, video recording, and a full test runner, use Playwright. It's excellent at that.
This is for the other 80%: scraping a page, filling a form on a schedule, checking that a site still works, letting an agent do something in a browser without babysitting a driver. The jobs where Selenium felt like bringing a crane to hang a picture frame.
The details
It's called NTXM Browser Mini. It's free, it's a Windows app, and the installer is on the download page. The code lives on GitHub if you want to look at how the API is put together.
If you try it, I'd genuinely like to know what breaks. It's a young tool, and the fastest way it gets better is people using it for real jobs and telling me where it falls short.
Download: https://ntxm.org/products/techxcelerate/browser-mini/
GitHub: https://github.com/techxcelerate/browser-mini
Top comments (1)
Keeping the logged-in browser visible is useful for scheduled jobs that occasionally need a human to inspect state. I would add an idempotency key to /act before letting an agent retry a timeout: a lost HTTP response after clicking Submit could otherwise become two submissions. Does the session API expose the action result history, or only the current page state?