Browser Use 1.0 Drops 80% of Its Code and Gets 5x Cheaper

Browser Use 1.0 removes 136,866 lines, roughly 80% of the library, according to the project’s release notes. The rewrite strips out DOM serializers, structured action spaces, and custom tool schemas. Its core premise is that those abstractions were limiting current models while adding cost and latency.

The new agent writes Python in a persistent read-eval-print loop connected to Chrome through the Chrome DevTools Protocol, or CDP, the browser’s debugging and automation interface. A generated cell might contain new_tab(url); bu.click(41); js(...). Browser Use executes it against Chrome and returns plain-text output for the next model turn.

State persists across turns, allowing the model to retain variables, inspect previous results, and compose browser operations with ordinary Python. The design gives the model a general programming surface while removing the layer that previously converted a page’s DOM into a specialized representation and restricted actions to a predefined vocabulary.

The score gap includes an outage

Across the models in its release comparison, Browser Use reports benchmark gains of up to 33 points when matched on the underlying model. The team also reports cost per task falling by factors of 2.7 to 5.2 and execution running two to three times faster.

BU Bench v2 contains 60 tasks, each repeated three times in cloud browsers. In the ultrafast configuration, version 1.0 scored 62.5, compared with 56.3 for the previous Browser Use Pi agent.

An OpenAI outage affected the benchmark window. The Pi agent recorded provider errors in 18 of 180 runs, while version 1.0 recorded one. After adjusting for those failures, the team found that the paired score difference was not statistically significant. The reported cost and latency improvements remained.

Python takes over the action loop

Installation for the default Browser Use model requires the package and a Browser Use API key:

uv add 'browser-use==1.0.0'
export BROWSER_USE_API_KEY=bu_...

A synchronous agent run takes three lines of Python:

from browser_use import Agent

agent = Agent('Find the number of stars of the browser-use repo')
print(agent.run_sync().final_result())

Defaults that changed

• llm=None now selects bu-fast through the Browser Use gateway.
• Browser() now creates a Browser Use Cloud browser.
• Browser('chromium') launches a local Chromium browser.
• Authentication uses one BROWSER_USE_API_KEY or the browser-use login command.
• The default max_steps value falls from 500 to 100.
• The default timeout is 1,700 seconds.

Applications can supply their own model through ChatOpenAI, ChatAnthropic, ChatGoogle, or a Pydantic AI model string such as llm='groq:llama-3.3-70b-versatile'.

Breaking changes fail early

Migration begins with the project’s migration guide. Unsupported 0.x options raise a TypeError that names the offending argument before a browser starts or billable work begins.

Some legacy tuning options remain temporarily accepted to ease upgrades. Parameters such as use_vision=True, flash_mode, and max_failures emit a warning once and are ignored. Removed imports raise an ImportError that identifies the replacement, preventing silent compatibility failures.

Long requests get more room

Every OpenAI Responses request now streams. The runtime allows 300 seconds for the first event and up to 930 seconds while events continue, preventing an active bu-smart turn from hitting the previous fixed 300-second boundary.

Version 1.0 also retries one transient failure, including failures that can occur after an HTTP 200 response. Automatic context compaction condenses prior history when the next request would exceed the model’s context window.

A smaller core shifts the trade-offs

Many browser-agent frameworks convert the DOM into model-readable tokens and expose a fixed set of actions such as click, type, and scroll. Browser Use 1.0 tests an architecture built around the coding ability of current models: Python supplies control flow and state, while CDP supplies browser access.

The project’s benchmark indicates that this approach can improve cost and latency without reducing task performance. Broader conclusions require results from independent suites, varied websites, longer workflows, and models outside the release comparison.

Generated Python also expands the execution surface that production teams must review. Deployment plans should establish where the code runs, which environment variables and files it can access, what network permissions it receives, and how untrusted page content is handled. Those controls matter when browser sessions contain authenticated accounts or sensitive data.

Pins and browser modes narrow deployment

• Every dependency is pinned with ==, and the lockfile is committed. Projects requiring different versions of pydantic, pydantic-ai-slim, mcp, google-genai, or pillow may encounter resolver conflicts.
• google-genai remains below version 3 because version 3.0.0 calls the Gemini API through v1, which rejects tools.
• Viewport emulation currently works with Browser('chromium') and remains unavailable for Browser Use Cloud browsers.

A production trial needs controls

Because the maintainers plan to release quickly and recommend exact version pins, an evaluation should use an isolated environment and a representative workload.

1. Pin browser-use==1.0.0 and confirm that the exact dependency set resolves alongside the application.
2. Replay real tasks while recording completion rate, provider errors, token cost, and wall-clock time separately.
3. Verify the 100-step limit and 1,700-second timeout against longer workflows.
4. Test local and cloud browser modes, including authentication, viewport requirements, downloads, and session persistence.
5. Audit generated-code execution, secrets exposure, network access, logging, and isolation before using authenticated sessions.

For web automation, layout-tolerant scraping, QA, and research agents, the release provides a concrete architecture to measure against an existing stack. Representative task completion, total provider cost, latency, migration effort, and execution controls will determine whether the smaller core fits a production system.