I just launched a browser API built for AI agents and LLMs
Hi Indie Hackers,
I've been working on browserbeam.com, and today I'm making the first public announcement. It's live.
But wait, did I just build Yet-Another-Browser-API nobody asked for?
That's a fair question.
There are already browser automation services out there: Browserless, Browserbase, Steel, and of course you can always spin up Playwright or Puppeteer yourself.
So, how is Browserbeam different?
Before building this, I was connecting LLMs to browsers using Playwright, and 10 out of 10 times the same problems came up.
The LLM gets back raw HTML. Thousands of tokens of markup noise. No signal for when the page is done loading. CSS selectors that break when the site changes. Cookie banners that waste agent actions. And you're managing Chrome processes on top of all that.
The existing browser APIs? They give you hosted Playwright. Same raw HTML, same problems. They solved the infrastructure part but not the "LLMs can't work with this data" part.
So I made the following commitment: build a browser API that returns what LLMs actually need, not what browsers produce.
Browserbeam is a REST API. You send JSON, you get structured JSON back:
- Markdown content instead of raw HTML
- Interactive elements with short refs (e1, e2) so the agent clicks by ref, not CSS selector
- A stability signal that tells you when the page is ready
- A diff showing what changed after each action
- Cookie banners and popups dismissed automatically
- Declarative extraction: describe the shape you want, get clean JSON
One POST request replaces ~25 lines of Puppeteer code.
Official SDKs for Python, TypeScript, Ruby. MCP server for Cursor and Claude Desktop.
Pricing is runtime-based: you pay for the wall-clock time your sessions are open. No credits, no bandwidth metering.
- Free trial: 1 hour of runtime, no credit card
- Starter: $29/mo (100 hours)
- Pro: $99/mo (500 hours)
- Scale: $199/mo (1,500 hours)
Would love feedback from fellow indie hackers:
- Does the "browser API for LLMs" framing resonate, or is it too niche?
- Is runtime-based pricing intuitive?
- What use cases come to mind for you?
Browser APIs for agents live or die on ugly edge cases, not the happy path. The stuff builders will ask fast is how you handle auth flows, retries, session persistence, anti-bot friction, and whether a failed run is easy to inspect. If your launch page leans into those tradeoffs instead of just "browser for agents," you'll stand out from plain Playwright wrappers.
Congrats for the launch, it's a cool product with a different twist.
Did you build the cloud browser infrastructure yourself, or you built your API on top of an existing one? Does it do anything to avoid getting detected and blocked?
Hey Rodrigo, thank you!
I see you are also in the API building business, nice product by the way :)
Yes, I built the browser infra myself.
Regarding the detection/blocking - it does not use proxies (at least for now) because that will raise the prices 2x at least. Been there. Maybe some day.
For now it offers the (BYOP - bring your own proxy) option.
Get up to $200K in GCP credits (24 months)
Eligible AI businesses can access up to $200K in GCP credits (24 months)
*Note : only for AI teams who are focused to build profitable scalable businesses models from day 1
If intrested dm to sai rithvik linkedin account
The structured JSON output is the right call — raw HTML is genuinely unusable for agents at scale. The short ref system for interactive elements is clever, solves the CSS selector fragility problem cleanly. On pricing: runtime-based is intuitive for infrastructure but it creates anxiety for agent workflows where you don't control how long a session runs. A cap or timeout guarantee per session would reduce that uncertainty. What's the typical session length for a standard scraping task?
Thanks! The pricing anxiety point is valid, so worth clarifying: every plan has a hard session timeout built in. Starter caps at 15 min, Pro at 30 min, Scale at 1 hour. The session closes automatically when the timeout hits, so there's no risk of a runaway session eating your runtime.
In practice, most scraping tasks (navigate, extract, close) finish in under 30 seconds. Multi-step workflows with form filling and pagination tend to land between 1-3 minutes. The long sessions are usually agents doing open-ended browsing where the task length isn't predictable upfront.
You also set a custom timeout per session at creation, so you can enforce your own cap below the plan limit.