The short answer, before anything else: pick Playwright when you can write the steps (known sites, high volume, no per-step model bill), and Browser Use when you can't (unfamiliar or constantly redesigned sites). Their failure modes are opposites: Playwright fails loudly with a stack trace; Browser Use can fail silently, hallucinating plausible data with no warning.
An explicit task plus your own logins fits neither default. That combination is where ego (lite) sits: a free browser built for sharing your logged-in state with agents like Claude Code and Codex, where every site you've signed into stays signed in and the agent works in an isolated Space that never takes your window.
Here's a detail most Browser Use vs Playwright articles miss: Browser Use used to run on Playwright, and left. Since v0.6.0 (August 2025) it drives Chromium directly over CDP with its own typed bindings.
That migration is the comparison in miniature. Playwright is a deterministic code framework built for humans writing repeatable scripts; Browser Use is an LLM agent loop that needed lower-level, faster, more forgiving browser access than a testing framework wants to give.
What's the real difference in positioning?
Playwright is scripted control: you (or your coding agent) write selectors and steps, the framework executes them identically every run, with auto-waiting smoothing the timing. Costs are compute and proxies; there's no per-step model bill. When the site changes a class name, the script breaks, visibly.
Browser Use is delegated control: Agent(task="find the three cheapest flights", llm=...) and the loop perceives, decides, and acts on its own. No selector research, tolerance for redesigned layouts, and a model round trip on every step: capture state, send to LLM, receive action, execute, repeat. Its cloud adds hosted models, proxies, and CAPTCHA handling on top.
Same foundation underneath, two different owners of the decision loop. Everything else in this comparison falls out of that.
The same job in both dialects makes it concrete:
// Playwright: you own the steps
const rows = await page.$$eval('.product', els =>
els.map(e => ({ name: e.querySelector('h3')?.innerText,
price: e.querySelector('.price')?.innerText })))
# Browser Use: the loop owns the steps
agent = Agent(task="List every product name and price on this page",
llm=llm, output_model=Products)
result = await agent.run()Longer but transparent versus shorter but opaque, as the Scrapfly comparison put it. Both lines are true at once.
That's the API on paper. Here's the same task from two recorded sessions: a real Playwright script and a real Browser Use agent run, captured against the same page (Hacker News) a few minutes apart, so the two are directly comparable.
# Playwright: raw Python script, fresh headless Chromium, no login state
from playwright.sync_api import sync_playwright
import time
t0 = time.time()
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
page.goto("https://news.ycombinator.com/", wait_until="load", timeout=20000)
title = page.title()
top_story = page.locator(".athing .titleline > a").first.inner_text()
points = page.locator(".subtext .score").first.inner_text()
print({"title": title, "url": page.url, "topStory": top_story, "points": points})
browser.close()
print(f"elapsed_s: {round(time.time()-t0, 2)}")
# Real output:
{'title': 'Hacker News', 'url': 'https://news.ycombinator.com/', 'topStory': 'Qwen 3.8 27B', 'points': '414 points'}
elapsed_s: 1.8# Browser Use: real Agent run, browser-use 0.13.7, gpt-4.1-mini via OPENAI_API_KEY
import asyncio
from browser_use import Agent, ChatOpenAI
async def main():
llm = ChatOpenAI(model="gpt-4.1-mini")
agent = Agent(
task="Go to https://news.ycombinator.com/ and tell me the exact title text of the #1 story on the front page, plus its points count.",
llm=llm,
)
history = await agent.run(max_steps=8)
print("FINAL RESULT:", history.final_result())
asyncio.run(main())
# Real output (trimmed to the meaningful lines):
INFO [Agent] Starting a browser-use agent with version 0.13.7, with provider=openai and model=gpt-4.1-mini
INFO [Agent] ▶️ navigate: url: https://news.ycombinator.com/, new_tab: False
INFO [tools] 🔗 Navigated to https://news.ycombinator.com/
INFO [Agent]
INFO [Agent] 📍 Step 1:
INFO [Agent] 👍 Eval: Successfully located the #1 story title and its points count on the Hacker News front page.
INFO [Agent] 🧠 Memory: Located the top story on Hacker News with title 'Qwen 3.8 27B' and points count '415 points'.
INFO [Agent] 🎯 Next goal: Report the exact title text and points count of the #1 story to the user.
INFO [Agent] ▶️ done: text: The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points., success: True, files_to_display: None
INFO [Agent]
📄 Final Result:
The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points.
INFO [Agent] ✅ Task completed successfully
FINAL RESULT: The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points.The points count reads 414 in one recording and 415 in the other because Hacker News vote totals change in real time between runs a few minutes apart, not because either number is made up.
Why did Browser Use itself leave Playwright?
Their engineering post on the migration is unusually frank, and worth reading as a review of Playwright from its heaviest user. Three reasons stand out.
Latency: Playwright routes every command through a Node.js relay, which "incurs a meaningful amount of latency when we do thousands of CDP calls" per task.
State drift: with state split across browser, relay, and Python client, "the node.js process can hang indefinitely waiting for a browser reply," and the only fix was kill -9.
Sharp edges: full-page screenshots above ~16,000px "reliably crashes playwright," and of roughly 10 ways tabs crash, "Playwright handled about half of these well, and presented impassible barrier to solving the other half."
The honest reading cuts both ways. For agent infrastructure running thousands of steps per eval, Playwright's abstraction stopped paying for itself. For the rest of us writing dozens-of-steps scripts, those same abstractions (auto-waiting, unified API, cross-browser) are exactly the value, and none of those sharp edges bite at normal scale.
Infrastructure needs differ from user needs.
How do they fail differently?
This is the section that should decide your choice, because you'll spend more time on failures than successes in scraping.
Playwright fails loudly. A broken selector throws a specific, reproducible TimeoutError with a stack trace; you fix the line and the failure never lies to you. The price is brittleness: cosmetic site changes break scripts that were logically fine.
Browser Use fails quietly. The documented risk pattern: when the agent can't find real data, it may produce plausible-looking prices or names with no error or warning, and the field reports match (a user watching it invent "123 Main St" for a form field).
Scrapfly's analysis of the two tools lands on advice worth framing: treat agent output like untrusted user input, validating formats, names, URLs, and empty fields before anything downstream consumes them.
There is now measured data on exactly this split. Real-World Bench runs a 31-task suite, most tasks on live production sites (Expedia, Redfin, X, Amazon, government data portals) plus a deterministic local site for the stateful checkout flow, through five tools with the same model (gpt-5.6-sol), the same judge, and up to 6 binary rubrics per task (154 across the 31 tasks); a task counts as perfect only if every rubric passes. On the Browser Use side it measured Browser Harness, Browser Use's local version (the hosted cloud product was not benchmarked); on the Playwright side it measured playwright-cli, the official CLI route for agents, not a hand-written script.
Real-World Bench: tasks finished with every rubric passing (%)
31-task suite against live sites, same model (gpt-5.6-sol) and same judge, best complete round per tool, run 2026-08-19
The interesting wrinkle is what partial credit hides. On average rubric score the two tie exactly: 88.9% for playwright-cli, 88.9% for Browser Harness. On tasks finished completely they diverge: 22 of 31 (71.0%) versus 26 of 31 (83.9%). Both routes collect partial credit at the same rate; the loop closes out more tasks. The mechanism is visible in the turn counts: Browser Harness averaged 51.2 model turns per task, the most of the five tools measured, which is the retry-until-it-works behavior doing its job, and also the chattiness you pay for. Its $2.55 average cost per task becomes $2.55 divided by 83.9%, or $3.04 per completed task; playwright-cli's $3.27 becomes $3.27 divided by 71.0%, or $4.61, because a failed run isn't free.
Which tasks belong to which tool?
Choose Playwright when the site is known and stable, volume is high, and cost per run matters: production pipelines, monitoring, regression testing. Choose Browser Use when sites are unfamiliar or frequently redesigned, when the task is research-shaped ("check these 40 vendors for X"), or when nobody's available to write and maintain scripts.
Two boundary cases sharpen the line. A daily price check on one known page is Playwright even though it sounds agent-y: writing the four-line script once beats paying an LLM to rediscover the page daily. A one-time survey across 30 differently-built directory sites is Browser Use even if you're a Playwright expert: thirty scrapers for thirty one-time reads is the wrong trade.
And the fair word for Browser Use's core strength: autonomous navigation of unfamiliar pages is genuinely hard, it's the best-known open-source system for it, and that capability is real even where this article recommends scripts. It's also, notably, a capability ego (lite) deliberately doesn't build; more on that next.
The combined option for logged-in work
Both defaults share a blind spot: your logged-in accounts. Playwright launches clean profiles; Browser Use connecting to a real Chrome profile has been reported unreliable, with the founder acknowledging the instability. Either way, tasks behind your own logins mean scripted auth and its maintenance.
ego (lite) is not a third framework; it combines what each column gets right. From Playwright it keeps explicit, code-written tasks (your agent writes the steps). What it adds is the thing neither column has: the browser is your real, signed-in one.
It's a free browser built for sharing your logged-in browser state with AI agents like Claude Code and Codex; every site you've signed into stays signed in, the agent writes JavaScript through the ego-browser skill so whole workflows run outside the model's context, and it works in an isolated Space that never takes your window.
It ran the same Real-World Bench tasks as the two tools above: 30 of 31 finished perfectly (96.8%), against Browser Harness's 26 of 31 and playwright-cli's 22 of 31. It used 30.3 model turns per task where Browser Harness used 51.2, because the agent batches whole workflows into one script instead of deciding step by step. At $1.92 average cost per task, the honest billing number works out to $1.92 divided by 96.8%, or $1.98 per completed task, against $3.04 and $4.61 for the other two. In the separate heredoc-vs-REPL benchmark, that same batching cut execution rounds 44%, tool calls 35.5%, and cost 21.6% versus command-at-a-time execution. It was also the fastest of the five tools measured, at 518 seconds per task average.
The resulting split, stated as one sentence per tool: Playwright for known public sites at scale, Browser Use for unfamiliar-site autonomy, ego (lite) for explicit tasks behind your own logins.
See the full ego (lite) vs Browser Use comparison, or download ego (lite) for Mac, free.
FAQ
Is Browser Use built on Playwright?
Not anymore. It ran on Playwright until v0.6.0 (August 2025), then moved to direct CDP control with its own typed Python bindings (cdp-use), citing relay latency, cross-runtime state drift, and unhandleable edge cases at agent scale.
Which is cheaper to run?
For a hand-written script, Playwright, almost always: no LLM calls in the loop, so cost is compute and proxies. Browser Use pays a model round trip per step, with user reports around 50K tokens per step on DOM-heavy pages. Once an agent is driving both, Real-World Bench has measured numbers: playwright-cli averaged $3.27 per task at 71.0% completion ($4.61 per completed task), Browser Harness $2.55 at 83.9% ($3.04 per completed task). For non-agent runs, the Scrapfly advice stands: log tokens on your own representative task.
Is there a benchmark that compares Browser Use and Playwright directly?
Yes, with two caveats about what was measured. Real-World Bench (the ego-browser-benchmark-framework repo on GitHub) ran a 31-task suite against live sites through five tools with the same model and an independent judge scoring up to 6 binary rubrics per task (154 across the 31 tasks). The Browser Use side was Browser Harness, Browser Use's local version, not the cloud product; the Playwright side was playwright-cli, the official CLI for agents, not a hand-written script. Results: Browser Harness finished 26 of 31 tasks perfectly (83.9%), playwright-cli 22 of 31 (71.0%), and the two tied at 88.9% average rubric score, meaning they collect partial credit equally and differ on finishing.
Can I combine Browser Use and Playwright?
Yes, and hybrid is a documented pattern: scripted steps for the predictable parts (login, pagination), the agent for variable-layout extraction, then script-side validation of what the agent returns. It also concentrates the LLM bill on only the steps that need judgment.
Does Browser Use handle CAPTCHAs and bot detection?
Its cloud tier advertises CAPTCHA handling and stealth browsers, while community threads continue reporting CAPTCHA problems as a live issue, so treat it as mitigation rather than a solved problem. On your own accounts, reusing a session you opened in a real browser avoids most of these walls without any stealth machinery.
Which should an AI coding agent like Claude Code use?
If you have a coding agent, it can write the steps, which removes Browser Use's main advantage for explicit tasks: have it write Playwright for public sites, or drive ego (lite) when the task needs your logged-in sessions. Reserve autonomous loops for genuinely unknown territory.
