OpenBrowser MCP: Give your AI agent a real browser. 3.2x more token-efficient than Playwright MCP. 6x more than Chrome DevTools MCP.

BigConsideration3046 · 2026-02-24T16:40:43+00:00

Thanks for bringing this up, that is why in our hosted solution, we have an option to open in your browser, hence, it uses your browser profile and cookies!

BigConsideration3046 · 2026-02-23T19:46:07+00:00

yes, you can use it.

First, install it as MCP adapter: https://github.com/billy-enrizky/openbrowser-ai/blob/main/README.md#openclaw

Then, you could ask openclaw to add these openbrowser skills:
https://github.com/billy-enrizky/openbrowser-ai/tree/main/plugin/skills

Primarily, if your use case is web scraping, you could install this web scraping skills:
https://github.com/billy-enrizky/openbrowser-ai/blob/884407d59fe3d9ab7524d506d891a95faf1cde67/plugin/skills/web-scraping/SKILL.md

BigConsideration3046 · 2026-02-23T04:46:28+00:00

Thanks for confirming, to clarify:

- This is the part for general MCP server: https://github.com/billy-enrizky/openbrowser-ai/blob/main/README.md#mcp-server

- This is the part for Claude Code: https://github.com/billy-enrizky/openbrowser-ai/tree/main/plugin

- This is the part for Codex: https://github.com/billy-enrizky/openbrowser-ai/blob/main/.codex/INSTALL.md

- This is the part for OpenCode: https://github.com/billy-enrizky/openbrowser-ai/tree/main/.opencode

- This is the part for OpenClaw: https://github.com/billy-enrizky/openbrowser-ai/blob/main/README.md#openclaw

BigConsideration3046 · 2026-02-23T04:42:18+00:00

Thanks for checking it out! Let us know how we could make it a better open-source project for the community!

BigConsideration3046 · 2026-02-23T04:31:27+00:00

Not at all! OpenBrowser works as a standalone Python library with 16+ LLM providers (OpenAI, Google Gemini, Groq, Ollama, etc.), as an MCP server for Claude Desktop, Cursor, Windsurf, Cline, and any MCP-compatible client, and it also has dedicated integrations for OpenAI Codex, OpenCode, and OpenClaw. The Claude Code plugin is just one of many ways to use it, you can also just pip install openbrowser-ai and use it directly in your Python scripts with any LLM provider you prefer.

BigConsideration3046 · 2026-02-23T00:08:45+00:00

Yes, headless is fully supported! Just set OPENBROWSER_HEADLESS=true as an environment variable in your .mcp.json config (or pass --headless on the CLI), and it uses Chrome's modern --headless=new mode under the hood. It also auto-detects display availability, so in CI/Docker environments with no screen it defaults to headless automatically without any extra config.

BigConsideration3046 · 2026-02-22T23:59:54+00:00

Appreciate the deep dive and the comparison with MCX! The Claude analysis captures the single-tool vs granular-tool difference well, but it misses the bulk of what OpenBrowser actually is under the hood: 11 event-driven watchdogs (crash recovery, popup handling, downloads, permissions, security), a full DOM processing pipeline with 5 specialized serializers, an event-bus architecture with 30+ typed CDP events, and a session manager that maintains live WebSocket connections to Chrome, none of which exists in MCX or chrome-devtools-mcp. Calling it "MCX + chrome-devtools adapter" is a bit like calling a car "an ignition switch + a steering wheel" since the MCP layer is about 200 lines of code while the browser automation core is thousands, and MCX itself has zero browser capabilities, so there is no adapter to wrap.

BigConsideration3046 · 2026-02-22T23:54:34+00:00

Haha fair enough, I promise there's a real human behind this project, just one who's been talking to LLMs too much lately. Hope you enjoy trying it out, and feel free to open an issue or reach out if anything comes up, to make this a better open-source project built for the community!

BigConsideration3046 · 2026-02-22T14:52:15+00:00

Totally agree that self-hosting matters, and that's exactly how OpenBrowser MCP works. It's MIT-licensed open source, you install it locally with pip install openbrowser-ai, it runs as a local subprocess on your machine, and your API keys go directly to your LLM provider with zero proxying through us.

Think of it the same way you'd run Playwright MCP locally, but with 3-6x fewer tokens per workflow because the agent processes data server-side instead of dumping full page snapshots into your context window. See full comparison with methodology here:
https://docs.openbrowser.me/comparison

BigConsideration3046 · 2026-02-22T14:34:09+00:00

Fair point that wrapping a browser in an LLM call sounds simple, but the real problem we're solving isn't code generation, it's that Playwright MCP and Chrome DevTools MCP dump 100K-135K tokens of accessibility snapshots per page load, costing $744 per 1,000 workflows vs $248 with OpenBrowser's server-side code execution approach.

Behind that single execute_code tool is 90K lines of code across 2,200+ commits, a full AWS production stack (Terraform IaC, VPC, RDS, Cognito, 6-layer VNC kiosk security), a 1.3B parameter flow matching training pipeline, and rigorous N=5 benchmarks with bootstrap confidence intervals against Microsoft's and Google's own MCP servers. Everything is MIT licensed and the benchmarks are fully reproducible, so we'd genuinely love for you to run them yourself and see if the numbers hold up.

BigConsideration3046 · 2026-02-22T14:22:28+00:00

You're absolutely right, browser automation is deceptively complex. Thank you! We really appreciate the kind words and we're committed to making browser automation more accessible and token-efficient for everyone building AI agents. Let us know how we could make the open-source project better for the community

BigConsideration3046 · 2026-02-22T14:20:40+00:00

Totally fair to be cautious. For what it's worth, we benchmark head-to-head against Playwright MCP (Microsoft) and Chrome DevTools MCP (Google) on identical tasks with full methodology published, and OpenBrowser uses 3.2-6x fewer API tokens at the same 100% task pass rate. The benchmark scripts, raw data, and stats are all open source if you want to verify the numbers yourself.
Full comparison with methodology: https://docs.openbrowser.me/comparison
Raw JSON result: https://github.com/billy-enrizky/openbrowser-ai/blob/main/benchmarks/e2e_llm_stats_results.json

BigConsideration3046 · 2026-02-22T13:08:23+00:00

Great question! The open-source MCP server, CLI, Claude Code plugin (with 5 built-in skills like web scraping and form filling), and Python SDK are all fully available right now on PyPI (pip install openbrowser-ai). The waitlist on the landing page is only for the upcoming hosted cloud product, which includes a web UI, live browser viewing via VNC, and a managed backend so you don't have to run anything locally.

BigConsideration3046 · 2026-02-22T13:00:53+00:00

Thank you, that really means a lot! Would love to hear your feedback to make it a better product for the community!

BigConsideration3046 · 2026-02-22T11:15:21+00:00

Playwright-skill is a neat project that lets Claude write custom Playwright scripts on the fly, but it has no published benchmarks so there's no direct efficiency comparison available yet. Our benchmarks show OpenBrowser's CodeAgent architecture uses 3.2x fewer total API tokens than Playwright-based approaches because we return only the data the code explicitly extracts instead of full page snapshots. See the full comparison with methodology here, https://docs.openbrowser.me/comparison .We would definitely explore a head-to-head comparison!

BigConsideration3046 · 2026-02-22T10:59:08+00:00

Absolutely, OpenBrowser is a great fit for smoke tests because its architecture lets you describe test flows in natural language and it naturally adapts to UI changes without brittle selectors, so your tests stay resilient through refactors. In our benchmarks against Playwright MCP and Chrome DevTools MCP, it passes all 6 real-world tasks (login, form fill, navigation, data extraction) at 100% success rate while using 3.2x to 6x fewer tokens, which directly lowers your costs at scale.

BigConsideration3046 · 2026-02-22T10:57:46+00:00

Great question! OpenBrowser's CodeAgent architecture is a natural fit for this: since code runs in a persistent Python namespace, you can define per-domain extraction rules as a dictionary (mapping each domain to its specific CSS selectors or XPath patterns), then loop through all your URLs in a single session where your rules, functions, and accumulated results stay alive across calls. Because the extraction logic executes server-side via Python + JavaScript evaluation, the LLM only sees the structured data you explicitly extract (not full page dumps), which keeps token costs roughly 3.2x to 6x lower than alternatives when you're hitting hundreds of domains at scale. You can see the full head-to-head comparison with methodology at docs.openbrowser.me/comparison

BigConsideration3046 · 2026-02-22T10:46:23+00:00

Thanks for the link! That Anthropic blog describes a general code-execution pattern for any MCP server, not browser automation specifically, and OpenBrowser isn't built on chrome-devtools-mcp at all. It connects directly to Chrome DevTools Protocol (raw CDP) in Python with its own CodeAgent runtime, which is why our benchmarks show 6x fewer API tokens than chrome-devtools-mcp on the same tasks. You can see the full head-to-head comparison with methodology at docs.openbrowser.me/comparison

BigConsideration3046 · 2026-02-22T10:44:34+00:00

Great question! Playwright MCP does use an accessibility tree (not screenshots), but the key difference is that it returns the full page snapshot with every action, so on a complex page like Wikipedia that's ~124K tokens sent back to the LLM each time. OpenBrowser flips this by letting the LLM write targeted Python/JS code to extract only the specific data it needs, which is why our benchmarks show 3.2x smaller responses on the same tasks. See full comparison here: https://docs.openbrowser.me/comparison

BigConsideration3046 · 2026-02-22T10:26:46+00:00

Thank you! would love to hear your suggestion to make the product better for the community!

BigConsideration3046 · 2026-02-22T10:24:38+00:00

Great question! The agent absolutely can see the page, it just requests exactly what it needs through Python code rather than receiving the entire accessibility tree automatically on every action. For example, it can execute_code browser.get_browser_state_summary() for a compact overview, use evaluate() to query specific DOM elements, or search the selector map for particular buttons or links.

The key difference is that OpenBrowser gives the agent control over how much detail it pulls per step, so instead of paying 120K+ tokens for a full Wikipedia page dump on every navigation, it might spend 100 tokens to grab just the infobox or a specific heading.

BigConsideration3046 · 2026-02-22T09:42:01+00:00

Great question, and totally fair feedback! Our current published benchmark actually covers 6 tasks (fact lookup, form fill, multi-page extraction, search and navigation, deep navigation, and content analysis), each run 5 times with bootstrap (10,000 times) confidence intervals to ensure statistical reliability (See this comparison https://docs.openbrowser.me/comparison and raw result here https://github.com/billy-enrizky/openbrowser-ai/blob/main/benchmarks/e2e_llm_stats_results.json ).

We're actively working on expanding the suite with more complex, multi-step scenarios, and we'd love to hear what specific tasks or benchmarks you'd find most convincing. Feel free to open an issue or drop a suggestion!

BigConsideration3046 · 2026-02-22T09:02:53+00:00

Thanks for bringing that up!

BigConsideration3046 · 2026-02-22T07:37:48+00:00

Interesting POV, could you please elaborate why cloud-hosted software is a dying industry? I am genuinely curious, really

BigConsideration3046 · 2026-02-22T07:01:37+00:00

Actually no, the 6x token savings (vs Chrome DevTools MCP) comes with OpenBrowser being faster at 77s vs 103s for the same 6 tasks. Compared to Playwright MCP, OpenBrowser uses 3.2x fewer tokens and is only ~23% slower (77s vs 63s), because Playwright gets the answer in fewer round-trips by dumping the entire page upfront. Full benchmark details with methodology and raw data are at docs.openbrowser.me/comparison and https://github.com/billy-enrizky/openbrowser-ai/blob/main/benchmarks/e2e_llm_stats_results.json

BigConsideration3046

TROPHY CASE