browser-use: a browser agent driven by natural-language goals

Lots of repetitive work can still only be done in a browser: looking things up on portals with no API, filling internal forms, comparing prices across sites, checking a sign-up flow. Traditional Selenium/Playwright scripts can do it but are brittle: one changed CSS class and they break. browser-use (repo browser-use/browser-use, MIT licence) takes a different approach: you describe the goal in natural language, and an LLM looks at the page and decides what to click, type and scroll. Its README calls it "the open-source browser agent".

Three ways to use it

Getting started with the library

Requires Python 3.11+. The README uses uv:

uv init --python 3.12
uv add browser-use
# add an API key to .env, e.g. ANTHROPIC_API_KEY=...

A minimal agent (rewritten following the README's structure, using Claude):

import asyncio
from browser_use import Agent, ChatAnthropic

async def main():
    agent = Agent(
        task="Go to browser-use's GitHub page and report the current star count",
        llm=ChatAnthropic(model="claude-sonnet-5-5"),
    )
    result = await agent.run()
    print(result)

asyncio.run(main())

For models, the README lists Browser Use's own BU2 model (optimised for browser tasks and recommended), direct wrappers ChatOpenAI, ChatAnthropic, ChatGoogle, and local models via Ollama (quality depends on your hardware).

Adding your own tools

The agent shouldn't do everything by clicking. When you have an internal API or need to save results, register Python functions as tools with Tools() and the @tools.action(...) decorator, then pass them to Agent(tools=...). A good pattern: the browser reads data from places without an API, your own tools write into your systems in a controlled way.

Real use cases

• Collecting data from portals without APIs: look up order status, invoices, appointments and export JSON.
• Natural-language smoke tests: "sign up a new account, check that the confirmation message appears".
• Market research: compare prices/features across several sites and compile a table.
• Letting coding agents check UI: after a frontend change, the agent opens the page and confirms.

Cost

The library is free, but every agent step is an LLM call carrying page state, so a 20-step task costs much more than a normal API call. Cloud browsers are billed separately (the README mentions about $0.02/hour, with stealth, proxies and CAPTCHA handling, but no guarantee of solving every CAPTCHA).

Risks and security notes

• Prompt injection from the web: the agent reads page content and can be "commanded" by hidden text. Don't give it logged-in sessions that can move money or delete data.
• Sensitive data in history: the README notes run history files may contain sensitive data. Use sensitive_data to pass secrets as placeholders, but page snapshots can still leak information; keep those files private.
• Profile sync only transfers cookies, not local storage/IndexedDB, so some sites will ask you to log in again.
• Website terms: automation may violate the target site's ToS. Check before running it on a schedule.
• Non-deterministic: the same task may take a different path each time. Work needing 100% stable results should still use traditional Playwright scripts.

How to apply it

• Dev: Use browser-use for "exploration" and infrequent tasks; once a flow is stable, consider moving it to a fixed Playwright script that's cheaper and more reliable.
• Tech Lead: Run agents in an isolated environment with least-privilege accounts. Log every step for audit.
• PM: Great for prototyping back-office process automation before investing in real API integrations.