Tabstack gives AI agents and apps finished output from the live web in a single API call. Extract structured data to a schema you define, convert pages to Markdown, run cited multi-source research, and automate browser tasks. Every call returns exactly what you asked for. Built for developers shipping autonomous agents and those adding web interaction to an existing app or stack. Built by Mozilla, with ephemeral processing, no model training on your data, and robots.txt compliance by default.
This is the 6th launch from Tabstack by Mozilla. View more
Tabstack Browser Automation
Launched this week
Give /automate a task in plain English and it drives a real browser to do it: navigate a site, click through a multi-step flow, fill a form, reach a page that only renders after interaction. The result streams back in one API call.
It's an API you call, not a framework you install. Browser and LLM included, nothing to host, no concurrency ceiling. Accessibility-tree automation spends 60 to 80% fewer tokens than screenshot-based agents.
Built by Mozilla. Ephemeral, no training on your data.
Launch Team / Built With
StartupBase
Not having to host the browser removes the exact part of web automation that always breaks in production. How are you handling sites with heavy bot detection, is that abstracted away or still on the developer side? Reading the accessibility tree instead of screenshots is a smart cost move too, that token math adds up fast at scale.
Tabstack by Mozilla
@attacomsian Thank you, that means a lot.
Bot detection: not abstracted away, not on you either. We run real browsers and respect robots.txt by default, so ordinary checks are usually fine. We don't do stealth or CAPTCHA-solving. If a site is set on keeping automation out, we won't fight it. That's a Mozilla call.
And yes on the accessibility tree. It's a cost decision as much as a reliability one, and screenshots get expensive fast. Glad that stood out.
Schema extraction in one call actually worked on a messy docs page, which was a nice surprise. The robots.txt compliance by default is a solid touch.
Tabstack by Mozilla
@toprak967471 Thank you, that's the best kind of surprise to hear about. And the robots.txt default isn't an accident, it's the Mozilla way. We think agents should access the web the way it asks to be accessed. Respecting that by default matters more to us than shipping a bypass. Appreciate you noticing it.
Hi Tessa, the fact that whatever I pull off the web stays mine is what makes this stand out to me. Anyone who has watched a scraper quietly break overnight will feel the relief here.
Tabstack by Mozilla
@robin_de_lacroix right?! Mozilla for the win. Their ethics around humans owning their data and being privacy-focused is a huge win for developers using Tabstack.
@tessak22 🙏🙏
Tabstack by Mozilla
Spot on. There are multiple products in the browser automation category. @Tabstack by Mozilla is different. Private by default. Transparent by design. Every call runs on a Mozilla-backed platform. The pages you extract, the answers you research, and the tasks you automate stay yours, handled responsibly and never used to train models.
Feels like a small tool but solves a daily frustration pretty well. How does this compare with just using Chrome tab groups in real workflows?
Tabstack by Mozilla
Tabstack by Mozilla
"Ditch your scraper. Make one API call with any tool." - @Tabstack by Mozilla
Tabstack by Mozilla
@thys_beesman There's no separate concurrency cap. What governs parallel tasks is a per-minute request rate limit, and it's per account (shared across every API key and every endpoint, not per key or per endpoint):
Trial / Individual: 10 requests/min
Team: 25 requests/min
Pro: 100 requests/min
Every response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset, so the clean pattern is to read X-RateLimit-Remaining off your successful calls and throttle before you hit zero. If you do go over, you get a 429 with a Retry-After header, and the SDKs retry that automatically with backoff.
So fire off as many tasks in parallel as you like: the limit you'll actually bump into is requests per minute, not a fixed number of concurrent connections.
Tabstack by Mozilla
to learn more about @Tabstack by Mozilla's per-minute request rate limits and usage, you can read the docs: docs.tabstack.ai/production/rate-limits
hope it helps!
That lines up with where we landed. When the target won't hand you a key, the only thing left is a read-before-write guard: a cheap check-run in front of the submit that asks does this record already exist and bails if it does. Costs you an extra call per write, but that beats a duplicate order showing up in someone's system after a blind retry. The nice thing is it lives entirely on my side, so I don't need Tabstack to persist anything.
Tabstack by Mozilla
@dipankar_sarkar Exactly right, and honestly that guard living on your side is the stronger design anyway. Idempotency belongs with whoever owns the write, not the tool making the call, so a cheap existence check before submit means your retry safety holds no matter what we do or don't persist. One extra read to dodge a duplicate order is a trade I'd take every time. Appreciate you sharing how you landed on it.
Tabstack by Mozilla
@starchet we're actually going to show off those kinds of use cases on our livestream later today! Currently, we don't have credential or session management, so the authentication into your social channels would be the trickier part. However, if you had a wrapper around Tabstack that you were feeding auth keys or cookie sessions to, it should work really really well. Watch our YouTube for the livestream—should be in 4 or so hours: https://www.youtube.com/@tabstackdev