Browser Use CLI 3.0 releases direct CDP control with 6× smaller context

• browser_use launch shipped Browser Use CLI 3.0 as a direct CDP browser-control layer via browser-harness, with support for cloud browsers and real Chrome.
• aibuilderclub_ breakdown says the main architectural change is removing the old click() / type() wrapper layer and avoiding DOM-tree stuffing in context.
• aibuilderclub_ breakdown also says 3.0 can remember login flows, selectors, and site edge cases, then write missing browser functions mid-task.
• browser_use benchmark reply says benchmarks are still coming, so the public launch evidence has the 6× context claim but not the eval table.

You can open the official CLI docs, browse the browser-use GitHub README, and read the design lineage in The Bitter Lesson of Agent Harnesses, where Browser Use argues that every click(), type(), and scroll() helper constrains the model.

Browser Use CLI 3.0 is a wrapper-deletion release. The official CLI page defines browser-use as a direct browser-control surface backed by Browser Harness: agents run Python to act in the browser, and the CLI manages the browser process.

That matches the browser-harness README, which describes the core path as “one websocket to Chrome, nothing between.” In the April design post, Browser Use argues CDP is the lowest level Chrome exposes and that LLMs have already seen the relevant APIs, including Page.navigate, DOM.querySelector, and Runtime.evaluate.

The official CLI page splits the runtime into three browser environments:

• Local Chrome or Chromium, preserving existing tabs, cookies, extensions, and logged-in sessions.
• Browser Use Cloud, for headless machines, isolated sessions, parallel sessions, persistent profiles, proxy routing, CAPTCHA handling, and live viewing.
• Any existing browser reachable through a CDP endpoint, configured with BU_CDP_URL or BU_CDP_WS.

That local mode is the practical hook for coding agents: a terminal agent can operate against the same authenticated browser state that most real web tasks depend on.

The integration path is a skill plus shell access. The browser-use README tells users to paste a setup prompt into Claude Code, Codex, or another coding agent so it installs or upgrades browser-use, registers the skill, and connects to the browser.

The CLI docs show the direct Python shape:

The Claude Code integration docs add a skills.sh route: npx skills add https://github.com/browser-use/browser-use --skill browser-use, then cloud login commands for Browser Use Cloud sessions.

The self-healing claim comes from Browser Harness. The browser-harness README lists editable agent workspace files: agent_helpers.py for helper code and domain-skills/ for reusable site-specific flows.

Browser Use’s April post describes the loop as normal coding-agent behavior:

• A helper is missing.
• The agent greps helpers.py.
• The agent adds the missing function.
• The task reruns.

The post’s upload example is concrete: the agent found no upload_file(), wrote one using DOM.setFileInputFiles, then switched to a chunked upload pattern after hitting a CDP websocket payload limit.

browser_use launch ties the release to “6× smaller, fewer tokens.” aibuilderclub_ breakdown attributes that to dropping the old wrapper layer and not stuffing a DOM tree into the model context.

The browser-use README frames CLI 3.0 as Browser Harness applied to Browser Use: give the model a direct browser surface instead of abstracting away browser complexity. Tiny harness, bigger action space. Christmas come early for coding-agent nerds.

In browser_use fewer-tools reply, browser_use answered “Yes, fewer tools” when asked about the surface area. In browser_use benchmark reply, browser_use clarified that “the browser-use cli itself is smaller” and said benchmarks are coming.