Browser Use 1.0 Deletes 80% of the Library — Agents Now Write Python Straight on CDP

On 10 November 2026 Browser Use cut 1.0.0. The changelog is blunt: the library lost 136,866 lines. The agent no longer drives a thick abstraction layer. It writes Python into one persistent REPL that talks straight to Chrome DevTools Protocol.

That is a real architectural shift. Most “browser agents” still sit on Playwright or Puppeteer wrappers that allocate, serialize, and round-trip through an extra process. Browser Use 1.0 collapses that. The model emits ordinary Python that calls CDP methods. The runtime keeps a single session alive. The cost of each action drops to whatever the protocol itself costs.

For anyone shipping real-time tools on Windows—overlays, live STT pipelines, interview helpers—the contrast is useful. Browser automation just got thinner. Native audio capture did not.

What “write Python on CDP” actually means

CDP is the same protocol Chrome DevTools uses. Targets, sessions, domains (Page, Network, Runtime, Input, etc.). A typical command is a JSON-RPC over WebSocket:

{"id": 1, "method": "Runtime.evaluate", "params": {"expression": "document.title"}}

Browser Use 1.0’s agent now generates Python that opens or reuses that socket and issues the calls directly. No intermediate task graph that gets compiled into Playwright steps. The persistent REPL keeps imports, handles, and state across turns. When the model decides to click, it emits the Input.dispatchMouseEvent (or the helper that wraps it) and continues.

The practical effects:

• Fewer process hops. The agent process and the browser talk over one WebSocket instead of agent → orchestrator → Playwright → browser.
• State lives in the REPL. Variables, page handles, and extracted data survive across model turns without re-serialization.
• The surface area is the protocol. If Chrome adds a domain, the agent can use it the next time the model sees the docs or an example. No library release required.

The default path still offers a cloud browser and their bu-fast model, but the open-source library now supports the same direct style locally.

Latency numbers that actually matter

A CDP round-trip on localhost is usually 1–4 ms once the socket is warm. Input events and Runtime.evaluate are cheap. The expensive parts remain:

• Browser process startup and target attachment (hundreds of ms cold).
• Page loads, network, and rendering.
• Model inference for the next Python snippet.

Compare that with a native Windows overlay that must stay under a few hundred milliseconds end-to-end for live speech:

Stage	Typical cost (native dual-track)	Typical cost (browser agent)
Audio capture quantum	5–10 ms (WASAPI shared)	N/A
Format convert + ring	1–3 ms	N/A
STT first partial	35–100 ms	N/A
Overlay paint	<16 ms	N/A
CDP command (warm)	—	1–4 ms
Full page action + model	—	200–2000 ms

Browser Use 1.0 makes the automation side faster and thinner. It does not shrink the WASAPI period or the model first-token time that dominates a live call overlay.

Where the thinner agent helps real tooling

The rewrite is useful exactly where developers already abuse browsers as programmable surfaces:

• Scraping and form filling that used to need a custom Playwright script can now be a one-shot natural-language task that emits the CDP calls.
• Testing an overlay or STT pipeline by driving a meeting page (join, mute, speak synthetic audio) becomes a short Python snippet the agent maintains in the REPL.
• Rate-limit and anti-bot workarounds that previously lived in a brittle wrapper can be expressed as direct Network and Fetch domain calls when the model is given the right context.

You still own the hard parts: keeping the WebSocket alive, handling target crashes, and not blocking the audio callback if you are also capturing system sound. The agent writes the browser side; the capture path stays in your process.

A minimal local shape that pairs with a Windows tool looks like this (conceptual):

# Persistent REPL state the agent keeps
from cdp import CDPSession  # whatever the 1.0 helpers expose
session = CDPSession.connect("ws://127.0.0.1:9222/devtools/browser/...")

# Agent-emitted turn
session.send("Page.navigate", {"url": "https://meet.example.com/abc"})
session.wait_for("Page.loadEventFired")
# later turns reuse the same session object

The key is that the session object and any extracted tokens live in the REPL. Next model turn can reference them without the orchestration layer re-hydrating everything.

Trade-offs that remain

• Cloud browser vs local Chrome: the hosted path adds network RTT and their stealth stack. Local keeps latency low but you manage profiles, extensions, and anti-bot yourself.
• Model quality on CDP: smaller models sometimes emit invalid params or forget to await events. The persistent REPL makes recovery cheaper (just emit a fix), but you still want a strong model or good few-shot examples for production.
• Concurrency: one REPL is simple. Parallel tabs or multiple meetings need either multiple sessions or careful target management. The old library hid some of that; now it is explicit.
• Audio and video capture: CDP can grab page media in limited ways, but it is not a substitute for WASAPI loopback when you need the system mix or a separate mic track for STT. Native capture still wins for latency-sensitive overlays.

Browser Use 1.0 is a clean example of removing abstraction when the protocol is already the right level. The same principle applies to the Windows audio path: stay as close to the engine period as possible, keep the callback allocation-free, and push everything else off the real-time thread.

I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.