So here’s the idea instead of a fragile selector chain: give an LLM a screenshot of the page and a goal, and let it figure out the clicks and keystrokes. The result? 105,000 GitHub stars and the fastest-growing open-source browser agent framework I’ve seen this year.

What browser-use Actually Does

So browser-use is a Python framework that wraps Playwright with an LLM-powered agent loop. You tell it a goal like “log into Gmail and find yesterday’s invoice,” and it handles the browsing, field detection, and error recovery itself. It also supports Claude, GPT-4o, Gemini, and local models through the standard OpenAI-compatible API. So you’re not locked into one provider.

But the magic is in the loop:

1. See — capture a screenshot + DOM snapshot of the current page
2. Think — the LLM decides the next action (click, type, scroll, wait)
3. Act — Playwright executes the action
4. Repeat — until the goal is reached or the agent decides it’s stuck

So no more page.waitForSelector('#submit-btn-2') that breaks when the dev team runs a new A/B test.

Quick Start — Took Me 3 Minutes

from browser_use import Agent
from langchain_openai import ChatOpenAI

agent = Agent(
    task="Go to Hacker News, find the top story, and summarize it",
    llm=ChatOpenAI(model="gpt-4o"),
)

result = await agent.run()
print(result)

That’s it. Three lines of Python and your AI agent has a browser. I ran this on my MacBook Air M3 and watched it go to news.ycombinator.com, scroll past the fold, click into the top thread, and return a crisp summary of the discussion. The whole loop took about 14 seconds for a three-step task. Not bad for a first run with no tuning.

Plus install is equally painless:

pip install browser-use playwright
playwright install

No Docker, no API proxy, no environment variables beyond your LLM provider key. It just works.

But heads-up — this isn’t free. Every action costs an LLM call, so the trade-off between convenience and cost depends on how often you run it. I set up a separate Claude Code Router config to keep per-task costs under control by switching models based on complexity.

How It Stacks Up Against Traditional Tools

So browser-use trades raw speed for resilience. Sure, a scripted Playwright test will always be faster — but it’ll also break more often. But for tasks where reliability matters more than milliseconds, the trade-off makes sense.

What to Watch Out For

Cost adds up. But each run calls an LLM multiple times. So for a task that needs 10 actions, you’re looking at 10+ inference calls. At GPT-4o prices, that’s roughly 2-10 cents per task. Still, fine for a few runs a day — expensive if you’re running thousands.

Slow for high-frequency tasks. The agent loop adds latency. A hardcoded Playwright script clicks in 50ms. Meanwhile browser-use takes 1-2 seconds per action just for the LLM to plan the next move. So not the tool for rate-limited scraping.

Still, if you’re after one-shot automation where the script would take longer to write than to run, this latency doesn’t matter much.

Auth flows are tricky. Sure, the agent can handle login forms, but CAPTCHAs and 2FA still block it. It can’t click "I am not a robot" — that requires a human or a CAPTCHA-solving service. I found this out the hard way when I tried automating a GitHub login — it worked right up until the 2FA prompt, then sat there staring at the verification code field like a lost tourist.

Memory on long tasks. But for multi-page workflows that run 20+ steps, the agent occasionally loses track of where it is. Sure, the prompt window fills up with past screenshots, and the LLM starts making weird decisions. Still, a 2026 fix is rolling out with Window observation (only recent actions), though it’s not fully stable yet.

The Bottom Line

Honestly, browser-use is the first framework that makes me believe in browser agents. It’s not ready to replace your Playwright test suite, but for one-off automation — data gathering, form-filling, demo generation — it’s genuinely useful today. Look, 105K stars aren’t hype; they’re developers who, like me, are tired of writing selectors that break by Friday. So yeah — give it a spin. Your future self, three hours into a debugging session, will thank you.