What happened
Browser Use’s GitHub release for version 1.0 says the project removed 80% of its library and started over. The agent now writes a Python cell in one persistent REPL; the REPL runs it in Chrome over CDP, then returns output to the model. The release describes this as removing the DOM serializer and action schema that previously sat between the model and browser. The package is installable as browser-use==1.0.0; the release directs users upgrading from 0.x to read MIGRATING.md first.
Several defaults change. In 0.x, Browser() used local Chromium; in 1.0 it creates a Browser Use Cloud browser. Browser('chromium') selects local Chromium, while Browser('chrome') attaches to a Chrome instance in the user’s profile directories when its DevToolsActivePort is present. The default run() limit falls from 500 steps to 100, with one step defined as one model request. The release says llm=None now selects bu-fast on the Browser Use gateway, and that the ultrafast accessibility-tree mode is enabled by default for bu-fast and bu-ultrafast.
The project says removed options that 1.0 cannot honor raise a TypeError before a browser starts or billing begins; removed imports raise an ImportError naming a replacement. Some obsolete tuning options instead warn once and are ignored. Once configuration checks pass, run() returns an error status for rejected keys or models, browser startup failures, and failures during a run. A missing key still raises before browser creation. The release also lists domain restrictions, uploads and downloads, typed structured results, sensitive-data redaction, web search billed to the Browser Use key, and CLI/MCP interfaces. It explicitly says the Python REPL is not a sandbox.
Its BU Bench v2 ran 60 tasks three times each on cloud browsers on November 9, 2026. Browser Use 1.0 in ultrafast mode scored 62.5% (95% CI 58.3–66.5), at $0.070 and 650 seconds per task. Browser Use Pi scored 56.3% (50.2–62.4), at $0.082 and 743 seconds. Both used gpt-6-luna via api.openai.com, with gpt-5.6-luna judging. The release says an OpenAI outage affected the test; after excluding provider errors, the paired quality difference was not significant, while the estimated cost and time differences favored 1.0.
What the archive adds
New Runtime’s earlier coverage of Stagehand v4 described browser-agent state and policy moving closer to the browser; that was a distinct SDK release, not this event: Stagehand v4 moves browser-agent state and policy closer to the browser (August 14, 2026). Browser Use 1.0 is a new release with a different implementation and its own migration and benchmark claims.
Trend signal
This release supports the idea that production agent behavior depends on the harness as much as on model choice: Browser Use changed the execution interface around a persistent REPL, while reporting results with the same model in both benchmark arms. That is a concrete example of the harness architecture outliving model choice, though one vendor’s benchmark does not establish a general performance result.
Why now
The release is a major version reset rather than a routine patch: its authors say they removed 80% of the library, changed defaults, and require migration review for 0.x users. The benchmark is dated November 9, 2026, the same date identified in the release notes.
Why it matters
For teams building browser agents, the execution boundary determines what the model can inspect and do, how state persists, and where safety controls must sit. A Python REPL directly connected to the browser can make actions more expressive than a fixed action schema, but it also means teams must treat generated code and browser access as runtime risks. The release’s own warning that this is not a sandbox matters: redacting secrets from outputs is not equivalent to constraining execution.
The changed defaults can also cause a migration to behave differently in production. Browser() now provisions a cloud browser rather than local Chromium, and a run permits fewer model requests by default. Teams should pin the version, read the migration guide, set local versus cloud mode explicitly, and validate allowed or prohibited domains before moving existing workflows. The benchmark suggests possible cost and latency advantages, but the outage-adjusted comparison does not show a significant quality difference, and the test is the project’s own.
Limits and uncertainty
The benchmark covers 60 tasks with three repetitions, and the release says an OpenAI outage distorted the raw comparison. Its outage-adjusted paired quality estimate is not statistically significant; results may not transfer to other workloads, models, or browser configurations. The release does not establish independent replication of the benchmark. It also identifies constraints: exact dependency pins can prevent installation alongside projects requiring other versions, viewport emulation is not available on cloud browsers, and the Python REPL is not a sandbox. The announcement does not quantify cloud-browser and proxy charges in its per-task figures; it says result.cost_usd covers model and web-search charges, not those costs.
Skill to build now
Run a migration rehearsal before switching a production workflow: pin browser-use==1.0.0, read MIGRATING.md, explicitly choose Browser('chromium') for local tasks or the cloud default for cloud tasks, and test representative jobs with a deliberate max_steps limit. Add domain restrictions and verify that secrets do not appear in cell output, checkpoints, or tool results; redaction is not a substitute for a sandbox.
Reader takeaway
Browser Use 1.0 is a substantive change to how its agent executes browser work, not just a faster version of the same API. Its benchmark makes a promising but vendor-reported case for lower cost and time, while migration changes and the lack of a sandbox demand a careful, explicit runtime setup.