Most AI browser agents are slow — and not because of the model. Every click takes three hundred milliseconds, every page load takes two seconds, every state call dumps a few thousand tokens of accessibility tree into the context window because the agent cannot tell which of the forty divs on the page is the submit button. By the time the model has thought about the page, the page has changed, and the agent re-asks. The user waits. The bill grows. The agent loops.

Browser-Use, the open-source browser-agent framework that hit 89.1% on WebVoyager, has been the most popular wrapper around this problem since late 2024. CLI 2.0, shipped late May 2026, is the first release that addresses the right layer: the browser itself. I would bet on it becoming the default harness for every CLI coding agent by Q4 2026.

Here is the part of the post where I tell you what was actually shipped.

Stop Using Playwright. Use CDP Directly.

The headline of CLI 2.0 is not the agent. It is the deletion of Playwright. The old Browser-Use was built on top of Playwright, which is built on top of WebDriver, which is built on top of a JSON-over-HTTP protocol Microsoft introduced in 2009 and has been quietly dying ever since. Every click, every navigation, every DOM query went through three layers of abstraction. The round-trip was the bottleneck.

CLI 2.0 talks to Chrome directly via the Chrome DevTools Protocol over a persistent WebSocket, with the browser running as a long-lived background daemon. Per-command cost — click, type, state — drops from roughly 250ms on Playwright to roughly 50ms on raw CDP. That is a 5x improvement, purely from removing software. No model change, no algorithm change, just less software between the agent and the browser.

The 50% token reduction comes from the same place. Playwright's accessibility-tree serialization is verbose, redundant, and full of noise the model has to read through. Browser-Use's state command returns a token-optimized element list: numbered interactable elements with their roles, names, and a one-line description. An agent does not need the parent chain, the CSS classes, or the ARIA-mirror div. It needs to know that element 7 is the "Submit" button. Browser-Use returns that and stops.

Let Me Show You What The Loop Actually Looks Like

```bash

Install once

curl -fsSL https://browser-use.com/cli/install.sh | bash

Start a session — launches a background Chrome daemon

browser-use open https://news.ycombinator.com

Get a token-efficient page state

browser-use state

→ [0] link "Hacker News" [1] link "new" [2] link "past"

→ [12] link "Show HN: Browser-Use 2.0" [13] link "84 comments"

Click by index — no CSS selectors to maintain

browser-use click 12

Type into the focused element

browser-use type "browser automation"

Screenshot if the agent needs eyes

browser-use screenshot page.png ```

Notice what is missing. There is no CSS selector. There is no XPath. There is no waitForSelector. The CLI returns numbered elements; the agent picks an index; the harness translates that back into a CDP call. Selectors break when pages change. Element indices computed on every state call do not. That is the design decision that makes Browser-Use better than any tool the agent could write for itself.

The CDP daemon also makes --profile "Default" and --connect work — you can attach to a real logged-in Chrome instance, keep your cookies, and stop fighting login flows. The same install ships a Claude Code / Codex / Aider skill via ~/.claude/skills/browser-use/SKILL.md, a quietly important detail: every CLI coding agent in 2026 will be talking to this daemon, and Browser-Use is positioning itself as the browser layer for all of them.

Who Should Use This

If you are building any agent that interacts with a real web app — login flows, form submission, scraping with structure, anything behind Cloudflare, anything that needs JavaScript to render — use Browser-Use CLI 2.0 as the browser layer. It is faster, cheaper, and more reliable than anything you can build in a weekend. The install is one shell command, the Chrome-only constraint is a feature, and the bill at the end of the month is roughly half of what Playwright-based agents cost.

If you only need to scrape static HTML, use curl. If you need headless Firefox, use Playwright directly. If you are doing one-off RAG over a docs site, do not pay the LLM cost — crawl it, chunk it, embed it. CLI 2.0 is for the 80% of agent-on-the-web use cases that need a real browser and a real login.

Who Should Not

If you are building a production agent that must support Safari, Firefox, or any non-Chromium browser, this is not for you. CDP is Chrome-only, and that is unlikely to change. The cloud tier covers some anti-bot detection, but it is not a substitute for a real cross-browser test suite. If you need to run the same automation on a real human's iPhone, you need something else.

The Take

The right way to build AI browser agents has been obvious for two years: talk to the browser at the lowest layer, return the smallest useful state, and stop pretending the model needs the full DOM. Browser-Use was the first to ship that, and CLI 2.0 is the first release that delivers the full version. The story is not the 14K+ stars or the 89.1% WebVoyager. The story is that someone finally treated the browser harness as infrastructure instead of bolting it on top of a testing framework never designed for agents. I would bet on this becoming the default browser layer for every coding agent that ships in 2027.

*Repo: github.com/browser-use/browser-use — MIT, 14K+ stars, Chrome/Chromium only, Python and TypeScript SDKs, Browser-Use Cloud for stealth/proxies. CLI 2.0 shipped late May 2026; WebVoyager 89.1% on 586 tasks is the published self-benchmark. Install: curl -fsSL https://browser-use.com/cli/install.sh | bash.*