Browser Use
Lets AI agents operate websites by opening pages, clicking, typing, and completing online tasks.
Per-dimension scores and reasoning
Evidence shows: The project provides CLI and Python library, allows custom tools and LLMs, but does not explicitly implement least privilege; user confirmation mechanism is absent, no user confirmation steps seen; data flow transparency is limited, README mentions telemetry but does not detail data flow; sensitive data handling, README mentions authentication and CAPTCHA handling but not how sensitive data is protected; dependency security, pyproject.toml pins dependency versions but no vulnerability scanning or security audit evidence; external effects, the project can automate browser actions but no explicit restrictions or warnings; rollback mechanism not mentioned; source attribution, README and pyproject.toml provide author info but publisher unverified. Deductions: missing user confirmation, rollback, insufficient data flow and sensitive data handling documentation.
Evidence shows: Internal consistency is good, README, pyproject.toml, and test files correspond; dependency availability, dependency list is complete and pinned but no availability guarantee; failure messages, test files have error handling but no user-friendly failure messages. Deductions: failure message design not fully demonstrated.
Evidence shows: README clearly distinguishes CLI and Python library use cases, suitable for different audiences; capability boundaries, README explains CLI and library scenarios but no explicit limits; trigger precision, CLI triggered by commands but no detailed trigger conditions; environment fit, pyproject.toml supports multiple platforms but no detailed system requirements. Deductions: trigger precision and system requirements insufficient.
Evidence shows: Information architecture is clear, README well-structured; install notes detailed, multiple installation methods; naming stability, multiple CLI aliases provided but no stability statement; examples and FAQ rich, multiple use cases; known limitations, README mentions production memory issues but not comprehensive; license MIT, clear; versioning and changelog, pyproject.toml has version but no changelog; maintenance responsibility, README provides author and community links. Deductions: missing changelog and comprehensive known limitations.
Evidence shows: Output usability, README shows various output formats (e.g., CSV, tables); marginal value, project provides unique browser automation capability; cost-benefit, README mentions free and open source but no detailed cost analysis. Deductions: cost-benefit analysis insufficient.
Evidence shows: Claims in README (e.g., benchmarks) lack specific data sources; cross-source corroboration, README mentions benchmarks and leaderboards but no links; fact-inference separation, README mixes facts and marketing language. Deductions: claims lack traceability, facts and inferences not clearly separated.
- Publisher identity unverified, proceed with caution.
- Lack of user confirmation mechanism, automated actions may pose risks.
- Insufficient documentation on data flow and sensitive data handling, further review needed.
- Dependencies pinned but no security audit, watch for dependency vulnerabilities.
What does this agent do, and when should you use it?
Browser Use is a browser-automation Python library and CLI built around interfaces including Agent, ChatBrowserUse, and Tools. Developers provide an Agent with a natural-language task and an LLM, then execute it with await agent.run() and receive a history result. The README demonstrates form completion, structured-data extraction, and QA for local websites, as well as custom Python tools. It can run for free on a user's own machine with a chosen LLM, while a hosted Cloud Agent and cloud browsers are offered for more complex or scaled workloads. The CLI is aimed at users of existing agents such as Codex or Claude Code, whereas the Python library is for developers embedding repeatable web automation into software.
A user constructs Agent(task=..., llm=...), where task is a natural-language web task and llm can be ChatBrowserUse, ChatOpenAI, or ChatAnthropic. The agent opens pages, clicks buttons, types text, and fills forms in a browser; documented example tasks include completing a job application from a resume, extracting structured follower data to CSV, and QA-testing a local website for bugs, usability issues, and visual inconsistencies. Execution uses await agent.run(), with the returned result assigned to history. For capabilities outside the browser, developers can create Tools(), register Python functions with @tools.action(description=...), and pass tools to Agent.
- A job seeker who needs an online application completed from their resume and personal information.
- An operations or research user who needs structured follower information extracted and exported as a CSV.
- A development team that needs a local website QA-tested before release, including reported bugs, usability issues, and visual inconsistencies.
- A software team embedding scheduled or parallel web automation for scraping, monitoring, or QA into its own application.
- A Codex or Claude Code user handling a one-off browser task, such as comparing laptop prices or uploading a video.
What are this agent's strengths and limitations?
- A single Agent interface handles page opening, clicking, typing, and form completion from a natural-language task.
- The Python library documents ChatBrowserUse, ChatOpenAI, and ChatAnthropic, plus extensibility through Tools and @tools.action custom Python functions.
- It offers both a CLI path for one-off agent-driven tasks and a Python-library path for embedded, scheduled, or parallel automation.
- The hosted Cloud Agent documents proxy rotation, CAPTCHA handling, persistent filesystem and memory, and more than 1,000 integrations.
- The Python library requires Python 3.11+ and usable LLM provider credentials; the open-source library is free, but model services may incur cost.
- Running many browser agents in parallel locally can consume substantial Chrome memory, which the README identifies as difficult to manage in production.
- CAPTCHA handling, browser fingerprinting, and proxy rotation are directed to the Cloud service; the README does not document those capabilities for the local open-source path.
- The README positions the hosted Cloud Agent as stronger for complex tasks, scaling, and production browser infrastructure, leaving local adopters to manage those concerns themselves.
How do you install or deploy this agent?
The Python library requires Python 3.11 or later. Install it with:
uv add browser-useor:
pip install browser-useConfigure at least one usable model credential in .env, for example:
BROWSER_USE_API_KEY=your-keyGOOGLE_API_KEY and ANTHROPIC_API_KEY are also shown as options. For an existing agent such as Codex or Claude Code, the README's setup prompt includes: browser-use skill install.
How do you use this agent?
Create and run a first agent:
import asyncio
from browser_use import Agent, ChatBrowserUseasync def main():
agent = Agent(task="Find the number of stars of the browser-use repo",
llm=ChatBrowserUse(model="openai/gpt-5.5"),
)
history = await agent.run()if __name__ == "__main__":
asyncio.run(main())The LLM can instead be ChatOpenAI or ChatAnthropic. With ChatBrowserUse, provider-prefixed model IDs documented in the README include anthropic/claude-sonnet-4-6, openai/gpt-5.5, and google/gemini-3-pro.
How does this agent compare with similar options?
Use the CLI for one-off browser tasks performed through an existing agent such as Codex or Claude Code; use the Python library for repeatable automation, monitoring, scraping, or QA implemented in code. The open-source agent runs on your own machine with deeper customization, while the hosted Cloud Agent is positioned for complex tasks and scale.