OpenBrowser-AI

Connect AI agents to browser through raw CDP

55 followers

Connect AI agents to browser through raw CDP

55 followers

OpenBrowser connects AI agents to browser through raw CDP. No abstraction layer. The LLM writes Python in a persistent namespace, batching operations per call. Page state at ~450 characters. Benchmarked against 3 frameworks on 6 real tasks: 100% accuracy across the board, 2.6x fewer tokens, 59% lower inference costs. Methodology is public and reproducible. MIT licensed. CLI + MCP server. 15 LLM providers. Two published RL studies training open-source models for browser control.

This is the 2nd launch from OpenBrowser-AI. View more

OpenBrowser-AI

Launching today

What if AI talked directly to your browser? 59% fewer tokens

OpenBrowser connects AI agents to Chrome through raw CDP. No abstraction layer. The LLM writes Python in a persistent namespace, batching operations per call. Page state at ~450 characters. Benchmarked against 3 frameworks on 6 real tasks: 100% accuracy across the board, 2.6x fewer tokens, 59% lower inference costs. Methodology is public and reproducible. MIT licensed. CLI + MCP server. 15 LLM providers. Two published RL studies training open-source models for browser control.

Free

Launch tags:Productivity•Open Source•Artificial Intelligence

Launch Team / Built With

getviktor.com — An AI coworker that actually does the work

An AI coworker that actually does the work

Promoted

OpenBrowser-AI

Maker

📌

We built OpenBrowser because we wanted to see what happens when an AI agent talks directly to Chrome. Most browser automation goes through an abstraction layer between the LLM and the browser. We took a different path: raw CDP (Chrome DevTools Protocol). The LLM writes Python code that executes in a persistent namespace, batching multiple browser operations into a single tool call. Page state compresses to ~450 characters. The architecture is simple, and it turns out simplicity saves tokens. We wanted numbers, not intuition. We benchmarked 4 CLI frameworks head-to-head on 6 real browser tasks using Claude Sonnet 4.6 on AWS Bedrock, N=3 runs with randomized order, 10,000-sample bootstrap confidence intervals. All four achieved 100% accuracy. OpenBrowser used 2.6x fewer tokens on average and won 5 of 6 tasks on token efficiency. Every framework in the benchmark is a good tool. Ours just found a way to do the same work with less. Full methodology and reproducible scripts: https://docs.openbrowser.me/cli-... Then we went further. We are post-training open-source models specifically for browser control. Two published studies: SFT + GRPO reinforcement learning on Qwen3-8B for web form filling, and a cross-paradigm comparison with diffusion language models. Both papers and all trained models are public on ResearchGate and HuggingFace. What ships today: - CLI tool and MCP server (pip install openbrowser-ai) - 15 LLM providers (OpenAI, Anthropic, Google, Bedrock, Azure, Ollama, and more) - Cloud platform with saved auth profiles and scheduled browser workflows - Raw CDP engine with code batching and persistent variable namespace This started as a capstone project at the University of Toronto. Four students, four months, one architectural question that turned into a framework, a cloud platform, and two research papers. We would love your feedback. What browser automation tasks would you throw at this? - GitHub: https://github.com/billy-enrizky... - Documentation: https://docs.openbrowser.me - Website / Waitlist: https://openbrowser.me - PyPI: https://pypi.org/project/openbro... - MCP Registry: https://registry.modelcontextpro... - YouTube Demo (5 min): https://youtu.be/F6Lzq0AHH2k

Report

14h ago

Previous OpenBrowser-AI Launches

OpenBrowser-AIConnect AI agents to browser through raw CDP

Launched on April 7th, 2026

Forum Threads

p/openbrowser-ai-59-less-100-accurate

•

2d ago

Same model, same tasks. 4 browser automation tools used wildly different amounts of tokens. Why?

I watched Claude read the same Wikipedia page 6 times to extract one fact. The answer was right there after the first read. But something about the tool interface kept making it look again.

That got me curious. If every browser automation tool can get the right answer, what actually determines how much it costs to get there?

So I ran a benchmark. 4 CLI browser automation tools. Same model (Claude Sonnet 4.6). Same 6 real-world tasks against live websites. Same single Bash tool wrapper. Randomized approach and task order. 3 runs each. 10,000-sample bootstrap confidence intervals.

The results (average tokens per task / wall time / tool calls):

View all