Launching today
fastbrowse
Fastest open source browser agent
148 followers
Fastest open source browser agent
148 followers
A fast open-source browser agent. It reads every button, link and field on the page and has a System One model (ex: jev) pick the next step from that list. If it's unsure, it falls back to a standard model model. Fast, cheap, and every answer provides a citation.
Free
Launch Team / Built With
Framer AI AgentsDesign and publish professional sites with AI
Promoted
Hey Product Hunt, I'm Furqan, one of the makers of fastbrowse.
Browser agents have become exceptionally popular, but there's some huge problems. They're slow, expensive and miss easy tasks.
A lot of them take a screenshot and have a slow model decide every step, so each task takes a while and the bill adds up.
Fastbrowse reads the elements on the page instead. Every button, link and field is handed to a System One model (like Jev) with a list of choices. This model decies what to do next, when it isn't sure, fastbrowse falls back to a LLM to get it right. And because it only picks from what's on the page, it can't click something that isn't there.
We tested this against the latest open-source browser agents agent: same sign-in and add-to-cart task on a demo shop, three runs each.
fastbrowse took 25.7 seconds and $0.020 a run. Browser Use took 42.2 seconds and $0.045. Both got it right every time. On a wider 46-task benchmark against Browser Use's hosted agent running Claude Opus, our median task cost $0.026 vs $0.284. 99.2% of tasks passed.
Fastbrowse produces citations for everything it referenced to get answers, so you can trust and verify the results.
It's MIT licensed, and the code, the benchmark harness and the raw results are all on GitHub: https://github.com/agent-labs-dev/fastbrowse
is the --secret value masked in the run replay too
@bbueno Yes! Any secrets fastbrowse itself injects (API keys, passwords from your vault) are masked in replays and never shown in text output. I'd still treat recordings as sensitive though as anything else that the page displays will still be visible.
Reading the elements instead of taking a screenshot for every step is the choice I'd want to understand first — especially with the 25.7-second, $0.020 run against Browser Use's 42.2 seconds and $0.045. When the small model is unsure and it falls back, does the citation trail still show which elements it was choosing between?
@jcbuilds Thats a good question, and currently we don't. I think it's a good idea though so I'll add it in and benchmark how it does, thanks for the idea!
Reading elements is basically the trick, passing a screenshot to an LLM is slower and more expensive, so for each step we just hand the model the element list from the page instead. When the model isn't confident, then we fall back to an image capable model with a screenshot.
Congrats on the launch! The quoted evidence sounds pretty neat, but just for observability purposes, if a page changes after the run, can someone still open a snapshot/screenshot and see what the browser saw at that moment?
Congrats on the launch, Furqan! Sharing the benchmark harness and raw results on GitHub is the kind of transparency that makes me trust a tool right away.
Question from the design side: since fastbrowse reads the elements instead of screenshots, how does it handle icon-only buttons with no label, or canvas-heavy UIs where there's barely any DOM to read? Feels like this approach quietly rewards apps with good accessibility, which I love.
We're launching on Product Hunt today too, good luck! 🚀
@erenasiroglu Great question, it actually handles it well more than you'd think. Most icons have a name that we can include in our control list. Anything with no obvious name that the model needs will read a screenshot as a fallback.
Canvas is pretty tricky though, we'd essentially go straight to reading screenshots there so efficiency and cost aren't as big of a win vs alternatives.
Seeing the list of element choices alongside the fallback would be useful when debugging a run. It gives you a way to check what the agent actually had available at that step.
"Can't click something that isn't there" is an underrated feature. Half of browser-agent debugging is discovering the button the model invented. Reading the DOM first is the right kind of boring. Congrats on the launch!