Browser Use

Browser Use is an open-source Python library that gives LLMs control over real browsers. It wraps Playwright with LLM-optimized DOM extraction, meaning models can act on a page without choking on thousands of tokens of raw HTML. The library supports Claude Sonnet 4.6, GPT-5, Gemini 3, and local models out of the box. With 93,000 GitHub stars and an active release cadence, it has become the de facto foundation layer for browser-agent products. The companion cloud platform adds stealth browsing, CAPTCHA solving, and residential proxies for teams that need production-grade browser infrastructure without managing it themselves.

If you’ve used a browser-agent product in the last eighteen months, there’s a reasonable chance Browser Use was running under the hood. The Python library that lets LLMs control real browsers has quietly become the plumbing for a significant slice of the browser-automation ecosystem. It has 93,000 GitHub stars, a release as recent as April 2026, and a long list of agent products that use it as their foundation layer. If you want to build your own browser agent rather than license someone else’s, Browser Use is almost certainly where you start.

Quick verdict

Browser Use is the right choice when you’re building a browser-agent product and want a solid, actively maintained open-source foundation. The library is free, MIT licensed, and supports every model you’d actually want to use. The cloud platform is the answer for production deployments where you need stealth browsing and CAPTCHA handling. It’s not a no-code tool and it’s not a finished product. It’s infrastructure.

What is Browser Use, exactly?

There’s a distinction worth making upfront: Browser Use is a library, not a product you deploy as-is. You write Python that imports it, configure an LLM, and write the agent logic yourself. What you get out of the box is a well-designed abstraction over Playwright that makes browser state digestible to language models and handles the low-level mechanics of interacting with pages.

The core problem Browser Use solves is that raw browser state is hostile to LLMs. A full page’s HTML can run to tens of thousands of tokens. Most of that is irrelevant structure, styling references, and tracking scripts. Sending all of it to a model is expensive and produces worse results than sending a clean representation of the interactive elements and visible content. Browser Use does that extraction for you.

On top of that, Browser Use handles the action loop: the LLM gets a representation of the page, decides what to do (click a button, fill a field, scroll, navigate), and Browser Use executes that action through Playwright and returns the updated page state. The loop runs until the LLM signals the task is complete or hits an error state.

The project launched in October 2024 and reached 50,000 stars within months, which reflects both genuine utility and good timing. Browser agents became a real topic in 2024, and there was a clear gap between “send a screenshot to a vision model” and “have a model reliably complete a multi-step form submission.” Browser Use filled that gap with a Python-first, Playwright-backed approach.

The cloud platform is a separate product that runs on top of the open-source library. It adds managed stealth browsers, CAPTCHA solving, a 195-country residential proxy network, and a TypeScript SDK alongside the Python one. Teams that want to run browser automation at scale without building their own browser fleet use the cloud platform. The two products share a brand and a codebase but serve meaningfully different use cases.

The features that made it the default browser-control library

LLM-friendly DOM extraction

The extraction layer is what separates Browser Use from writing Playwright scripts with LLM calls sprinkled in. Instead of dumping raw HTML, the library produces a structured representation of the page that includes interactive elements, visible text, and the relationships between them, stripped of everything that’s noise to a language model.

This matters for two reasons. First, token cost. A 200KB HTML page costs serious money to process repeatedly across a multi-step task. Browser Use’s extraction can bring that to a fraction of the raw size. Second, accuracy. Models make better decisions when the context they receive is signal, not signal buried in noise. The extraction layer is where Browser Use earns its existence as a library rather than a thin wrapper.

Multi-model support

The library ships with adapters for Claude Sonnet 4.6, GPT-5, Gemini 3 Flash, and Ollama for local models. Switching between them is a configuration change, not a rewrite. In practice, this means you can run your browser agent against whatever model is cheapest or fastest for your use case and swap if the landscape changes.

Browser Use also ships ChatBrowserUse, a model the team built specifically for browser tasks. The claim is 3 to 5 times faster task completion than general-purpose models with better accuracy on web automation benchmarks. It’s available through the cloud platform rather than as a standalone model. Whether it justifies the cloud subscription depends on how performance-sensitive your use case is.

Playwright foundation

Playwright is one of the more mature browser automation libraries in existence. It handles cross-browser support, stable element selection, waiting for network requests, handling popups and iframes, and dozens of other edge cases that would take months to get right from scratch. Browser Use inherits all of that by building on top of Playwright rather than reimplementing it.

This is not a minor point. Browser automation in production fails in weird ways. Elements that aren’t in the DOM yet, pages that load asynchronously, sites that detect and block automation. Playwright has years of fixes for these failure modes. Browser Use gets them for free and adds the LLM layer on top.

Cloud platform for production

The open-source library runs browsers locally or on your own infrastructure. That’s fine for development and for small-scale production use. It breaks down when you need to run at volume, avoid IP bans, or handle CAPTCHAs without manual intervention.

The Browser Use cloud platform solves that set of problems. It provides stealth browsers with fingerprint randomization that reduces bot detection, CAPTCHA solving integrated into the automation loop, and residential proxies across 195 countries for geographic distribution. Fortune 500 companies and AI teams are cited as customers.

The SDK for the cloud platform supports both Python and TypeScript, which broadens the audience beyond the pure Python library. Setup is an API key and a pip install browser-use-sdk, with the browser infrastructure managed entirely on Browser Use’s side.

Browser Use Director and orchestration

Director is Browser Use’s answer to the question of what happens when one browser agent isn’t enough. It’s an orchestration layer that coordinates multiple browser agents working in parallel, assigns tasks, and aggregates results. For scraping at scale, for form submissions across thousands of accounts, or for any task where parallelism matters, Director is what turns the library from a single-agent tool into a production workflow system.

The orchestration model fits naturally with how agent products are built: you write a high-level task, Director breaks it into steps and runs them across a pool of browser agents, and you get back structured results. It’s a thin abstraction over the underlying library, but it’s a useful one for teams building pipelines rather than one-off scripts.

Pricing

The open-source library costs nothing. You install it with uv add browser-use, bring your own LLM API keys, and pay whatever your chosen model provider charges for inference. For light use or development work, that’s the whole story.

The cloud platform is where pricing gets opaque. Browser Use doesn’t publish a pricing page with specific numbers, which is a real friction point if you’re trying to evaluate the total cost of a production deployment. You need to sign up and talk to the team to get actual numbers. Given that the platform includes stealth browsers, CAPTCHA solving, residential proxy coverage across 195 countries, and managed infrastructure, the cost is not going to be zero, and it shouldn’t be. That’s genuinely expensive infrastructure to provide.

The practical split works like this. If you’re a developer building an agent product for internal use or a small deployment, the open-source library plus your LLM API costs is probably sufficient. If you’re running browser automation at volume in a production setting where reliability, stealth, and geographic distribution matter, you’re looking at the cloud platform and the conversation with the sales team.

The absence of published pricing is a legitimate criticism. It makes budget estimation harder and introduces friction into the evaluation process that doesn’t serve the team’s interests given that the open-source library is already widely used and sends a warm audience their way.

Where Browser Use wins and where it doesn’t

Browser Use wins on every dimension related to its core purpose: a Python developer who wants to add browser control to an LLM application has no better starting point. The extraction layer is well thought out, the Playwright foundation is solid, the multi-model support means you’re not locked into a single provider, and the 93,000 stars represent genuine community adoption rather than marketing-driven metrics.

It wins for teams building agent products. If you’re the infrastructure layer under a browser-agent SaaS, Browser Use is what you’d build on. Several notable products in the space do exactly this.

Where it doesn’t win: it’s not a product for non-engineers. There’s no visual interface, no workflow builder, no way to describe a task in natural language and have it run without writing code. Tools like Skyvern and MultiOn target that audience. Browser Use is explicitly for developers.

The TypeScript gap is real for teams that don’t use Python. The cloud SDK supports TypeScript, but the full open-source library is Python-only. If your stack is Node-first, you’re either using the cloud SDK or wrapping the Python library in a subprocess, neither of which is ideal.

Production self-hosting is also non-trivial. Running browser automation at volume on your own infrastructure, with proper stealth and reliability, is an engineering problem in itself. The cloud platform solves it, but at a price that isn’t public.

Who Browser Use is built for

The primary audience is Python developers who are building browser-agent capabilities into their own products or pipelines. If you’re adding web interaction to a larger AI application, if you’re building a vertical-specific agent that needs to operate on particular websites, or if you’re evaluating LLM performance on web tasks for research purposes, Browser Use is the right starting layer.

AI teams that want production browser infrastructure without operating it themselves are the cloud platform’s target. The managed offering makes the most sense for teams that have validated the open-source library in development and need to move to a production environment with reliability and stealth requirements that self-hosting doesn’t easily meet.

Browser Use is not for product managers who want to automate personal workflows, for operations teams looking for an RPA replacement with a visual interface, or for companies that want a browser agent as a finished product they can hand to end users. That’s not a criticism. It’s a clear scope decision that reflects what the library is for.

Browser Use vs the alternatives

The comparison set depends on what you’re actually trying to do.

Skyvern is the closest in technical approach. Both use LLMs to understand pages and execute actions in real browsers. Skyvern leans further toward being a product: it has workflow management, a visual interface, and a cleaner path to production deployment for teams that don’t want to write much code. Browser Use gives you more control and costs less if you have the engineering capacity to use it. They’re not identical choices. Skyvern wins for teams that want a faster path to a working product. Browser Use wins for teams that want to build their own.

MultiOn approaches browser automation from a different direction. It’s a cloud-based agent service that handles all the browser complexity behind an API. You send a task in natural language and get back a result. There’s no library to configure, no model to choose. That’s ideal if you want to call a browser agent as a microservice. It’s limiting if you want to control the execution, choose your model, or run at volume with your own infrastructure decisions.

OpenAI Operator is the clearest example of the finished-product end of the spectrum. It runs in OpenAI’s infrastructure, uses OpenAI’s models, and is accessible to non-technical users through a chat interface. It’s not a library you build on. If your team wants to give business users a way to automate browser tasks without writing code, Operator is the more direct comparison. If your team wants to build that kind of product, Browser Use is what you’d use to build it. The Anthropic Computer Use API takes a similar model-level approach to computer control, though it operates at the OS level rather than the browser level.

For teams building production browser agents and wanting to evaluate across the whole space, our best AI agent for coding guide covers the broader agent landscape.

Getting started

Installation is two lines with uv, which is the recommended path:

uv init && uv add browser-use && uv sync
uvx browser-use install

The second command sets up Chromium. From there, you need an API key for your chosen LLM provider set as an environment variable, and you’re writing your first agent. The docs at docs.browser-use.com are genuinely useful and include working examples for common task types.

A minimal agent requires about 15 lines of Python. You import the Agent class, pass it an LLM instance and a task string, and call agent.run(). For most development use cases, that’s the whole setup.

For the cloud platform, you pip install browser-use-sdk, set BROWSER_USE_API_KEY, and switch your agent initialization to use the SDK’s client. The API design mirrors the open-source library closely enough that migrating between them is a small change rather than a rewrite.

Start with a task you can verify manually, something with a clear success state like filling a form or extracting specific information from a page. Browser automation is easier to debug when you know exactly what correct output looks like.

The bottom line

Browser Use is what it says it is: a well-built open-source layer between LLMs and real browsers. The 93,000 GitHub stars aren’t hype. The library solves a real problem well, ships regularly, and has become the foundation for a meaningful chunk of the browser-agent ecosystem. If you’re building a browser-capable AI application in Python, this is your starting point.

The cloud platform closes the gap between development library and production infrastructure, at a price that requires a conversation with the team. That opacity is the only thing worth holding against it. The product decision to be infrastructure rather than finished agent is the right one for the audience it’s actually serving.

Key features

• LLM-friendly DOM extraction that reduces token cost vs raw HTML
• Multi-model support including Claude Sonnet 4.6, GPT-5, Gemini 3, and local models via Ollama
• Built on Playwright for reliable cross-browser automation
• Cloud platform with stealth browsers, CAPTCHA solving, and 195-country proxy coverage
• Browser Use Director: multi-agent orchestration for parallel task execution
• Self-healing automation that adapts when page structure changes
• CLI and SDK interfaces for integration into existing Python projects

Pros and cons

Who is Browser Use for?

• Developers building browser-agent products who need a reliable automation foundation
• AI teams that want to add web interaction to an existing LLM pipeline without writing Playwright wrappers themselves
• Platform engineers evaluating whether to build or buy browser infrastructure for production agent deployments
• Researchers benchmarking LLM web-task performance across multiple model providers

Alternatives to Browser Use

If Browser Use isn't quite the right fit, the closest alternatives are skyvern , multion , and openai-operator . See our full Browser Use alternatives page for side-by-side comparisons.