TL;DR: Browser-Use is the most-adopted open-source browser agent in 2026 — MIT-licensed, ~103K GitHub stars, and it drives a real Chromium browser instead of scraping HTML. It runs on any OpenAI-compatible endpoint, so a local Ollama model costs $0 per task. The catch: small local models fail at multi-step web tasks that a frontier model handles, and local tool-calling needs a manual workaround. Run it for automation you can supervise; don’t expect a 7B model to book flights unattended.

	Browser-Use	Stagehand	Raw Playwright
Best for	Autonomous multi-step web tasks	Deterministic AI-assisted scripts	Fixed, hand-coded automation
Approach	Full agent loop (DOM + vision)	Per-action LLM calls (act/extract)	No LLM; you write selectors
Local LLM	Yes (Ollama, vLLM, LM Studio)	Yes (OpenAI-compatible)	N/A
The catch	Slower, needs a capable model	Less autonomous, more code	Breaks when the page changes

Honest take: If you want an agent that figures out the steps itself, Browser-Use is the one to start with — just pair it with a tool-calling-capable model and keep a human in the loop for anything that spends money.

What Browser-Use actually is

Browser-Use is a Python framework that lets a large language model operate a real web browser. You give it a task in plain English — “find the cheapest flight from Berlin to Lisbon next Tuesday” — and it opens Chromium, reads the page, decides what to click, clicks it, reads the next page, and repeats until the task is done.

The project came out of the YC W25 batch and has grown to roughly 103K GitHub stars as of mid-2026, making it the most-starred open-source browser agent by a wide margin. The core library is MIT-licensed — genuinely permissive, commercial use allowed, no attribution clause. The company layers a paid cloud service and a hosted model marketplace on top, but nothing about the open-source core is crippled to upsell you. You can run the entire stack locally at zero cost.

The current release at the time of writing is v0.13.3 (July 1, 2026). It requires Python 3.11+ and installs with a single command.

How it works: DOM plus vision

Most people assume a browser agent works by taking screenshots and “looking” at them. Browser-Use can do that, but its default path is DOM extraction — it reads the page’s underlying structure (buttons, links, form fields, text) and hands the model a compact, indexed representation of the interactive elements. The model picks an element by index and an action (“click element 14”, “type into element 7”), and Browser-Use executes it through Playwright.

Vision is optional and controlled by the use_vision parameter, which has three modes: "auto" (the model can request a screenshot when it needs one), True (always attach a screenshot), and False (never). There’s also a vision_detail_level knob for low/high/auto.

Why does this matter? Speed and cost. Screenshots are expensive — every step ships a full image to the model, and vision inference is slow. DOM-only steps are an order of magnitude faster and far cheaper in tokens. The tradeoff is that some pages (canvas apps, heavily obfuscated sites, image-only content) genuinely need pixels. The default auto mode is a sensible middle ground: text-first, pixels when necessary.

Under the hood it’s Playwright driving Chromium, which means it inherits Playwright’s reliability for waiting on elements, handling navigation, and managing browser contexts. That’s a real advantage over agents that reinvent browser control.

Installing Browser-Use

# Create a project and install
pip install browser-use

# Browser-Use uses Playwright's Chromium under the hood
playwright install chromium

A minimal script with a cloud model looks like this:

import asyncio
from browser_use import Agent, ChatOpenAI

async def main():
    agent = Agent(
        task="Find the number of stars on the browser-use GitHub repo",
        llm=ChatOpenAI(model="gpt-5.5"),
    )
    result = await agent.run()
    print(result)

if __name__ == "__main__":
    asyncio.run(main())

That’s the whole thing. The Agent runs a plan-act-observe loop until it decides the task is complete or hits a step limit.

Self-hosting with Ollama (the part that saves money)

Browser-Use connects to any provider that implements the OpenAI /v1/chat/completions schema, so a local Ollama server works as a drop-in backend. There’s a dedicated ChatOllama class, and you can also point ChatOpenAI at the Ollama endpoint.

from browser_use import Agent, ChatOllama

llm = ChatOllama(
    model="qwen3-coder-next:latest",
    base_url="http://localhost:11434",
    num_ctx=32768,      # critical — see below
    temperature=0.1,
)

agent = Agent(task="...", llm=llm)

Two settings make or break local runs:

1. num_ctx. Ollama defaults to a 2048-token context window. A browser agent’s prompt — task description, action list, and a serialized DOM — blows past that instantly, and the model silently truncates it, then behaves like it has amnesia. Set num_ctx to at least 32768. Going from 4K to 32K on an 8B model adds roughly 1–2 GB of KV-cache memory, so budget VRAM accordingly.

2. A tool-calling-capable model. Browser-Use drives the browser through function calls. If your model can’t emit clean tool calls, the agent takes zero actions and appears to hang. Qwen3-Coder-family models work well once tool-calling is enabled; see the Qwen3-Coder-Next local setup guide for the model side.

The local-model gotcha you’ll hit

There’s a known bug (issue #1978) where agent initialization fails with local LLMs because _detect_best_tool_calling_method() tries to probe the endpoint and throws Failed to connect to LLM. As of this writing there’s no upstream fix — the community workaround is to bypass auto-detection and force the function-calling method directly rather than letting Browser-Use guess. If you see a connection error at startup even though ollama serve is clearly running, this is why. Pin the tool-calling method explicitly and it goes away.

For hardware, a browser agent is not especially demanding on the model side — the bottleneck is context length, not raw parameter count. A 7B–14B model at Q4_K_M on a 12GB card like the RTX 3060 12GB runs comfortably; step through complex sites and you’ll want a RTX 3090 for the extra headroom and speed. For anything heavier, renting a GPU by the hour on RunPod is cheaper than buying until you’re running tasks daily. Full hardware breakdowns live on runaihome.com.

Where Browser-Use is the right choice

• You want autonomy, not a script. Browser-Use decides the steps. You don’t enumerate selectors or write a state machine — you describe the goal. That’s the whole pitch, and it delivers on cooperative sites.
• You need vision as a fallback. When a site is unreadable through the DOM, the agent can fall back to screenshots without you rewriting anything.
• You’re cost-sensitive. With a local model, per-task cost is electricity. For repetitive internal automation — filling forms, pulling dashboard data, monitoring listings — that’s transformative compared to per-call cloud pricing.
• You’re building on top of it. The MIT license and Playwright foundation make it a reasonable base layer for a larger product, which is exactly why so much of the agent ecosystem has standardized on it.

Where it falls short (the “when NOT to use it” section)

• Small local models struggle with long tasks. This is the honest limitation. A 7B model can click around a simple form, but ask it to complete a 15-step checkout flow with conditional branches and it loses the plot. Multi-step reliability tracks model capability closely, and local models under ~30B lag frontier models here. Don’t set a small local model loose on anything irreversible.
• It’s slow compared to deterministic tools. Every step is an LLM inference call. Benchmarks put vision-heavy agent runs at tens of seconds for a handful of actions, versus sub-second for hand-coded DOM automation. If the task is fixed and repeats thousands of times, a plain Playwright script or a lighter tool like Stagehand will be faster and cheaper.
• It’s non-deterministic. The same task can take different paths on different runs. For QA or anything requiring reproducible output, that’s a liability, not a feature.
• Anti-bot systems fight back. Cloudflare challenges, CAPTCHAs, and aggressive fingerprinting will stop the agent like they stop any automation. Browser-Use isn’t a bot-detection bypass, and using it to circumvent one is on you.
• Local tool-calling has rough edges. The _detect_best_tool_calling_method bug above is one of several friction points that only show up with local models. Cloud endpoints are noticeably smoother out of the box.

If your task is deterministic and high-volume, reach for raw Playwright. If you want AI assistance but tighter control, Stagehand’s per-action act/extract model gives you more predictability. Browser-Use wins specifically when you want the model to own the planning. For a broader look at open-source coding and agent tooling, aicoderscope.com covers the developer-agent side.

FAQ

Is Browser-Use really free? The core library is MIT-licensed and fully functional offline with a local model — free forever. The company sells an optional cloud runtime and hosted models, but you never have to touch them.

Do I need an OpenAI API key? No. Any OpenAI-compatible endpoint works, including a local Ollama, vLLM, or LM Studio server. Point ChatOllama or ChatOpenAI at http://localhost:11434 and you’re running for free.

Which local model should I use? Pick one with solid tool-calling — the Qwen3-Coder family is a reliable choice in 2026. Set num_ctx to at least 32K, and expect a capability ceiling: local models under ~30B handle short tasks well but stumble on long, branching flows.

Does it get past CAPTCHAs and Cloudflare? No. Browser-Use drives a real browser but includes no anti-detection tooling. Sites with strong bot defenses will block it.

How is it different from Playwright? Playwright is a browser-automation library you script by hand with selectors. Browser-Use puts an LLM on top of Playwright so you describe a goal in English and the model figures out the clicks. Playwright is faster and deterministic; Browser-Use is autonomous and adaptable.

Sources

• Browser-Use GitHub repository — license (MIT), v0.13.3 release, star count, quickstart
• Browser-Use — Y Combinator (W25) — batch, growth, project positioning
• Browser-Use docs: Supported Models — provider list, OpenAI-compatible endpoint support
• Browser-Use docs: Agent parameters — use_vision modes, vision_detail_level
• Issue #1978 — ChatOllama tool-calling detection bug — local-LLM initialization failure and workaround
• Ollama OpenAI compatibility — local endpoint schema and setup
• Stagehand vs Browser Use vs Playwright (NxCode, 2026) — speed and approach comparison

Recommended Gear

• RTX 3060 12GB — entry point for running a 7B–14B tool-calling model as the agent’s backend
• RTX 3090 — extra VRAM and speed headroom for longer contexts and heavier local models