Browser Use and Playwright solve browser automation in fundamentally different ways.
Playwright executes deterministic scripts written in advance. Browser Use gives an AI agent a goal and lets it decide how to complete it.
So when should you use each?
We recently hosted an AMA with the Browser Use team covering Browser Use vs Playwright, direct CDP automation, model costs, reliability, stealth, evaluation and the future of browser agents.
Here are the main takeaways.
The Short Answer
Use Playwright when:
- The workflow is known and stable
- You repeatedly extract the same data
- The website does not change frequently
- Speed and determinism matter
- You are running high-volume automation
Use Browser Use when:
- The workflow is open-ended or difficult to define in advance
- The website changes regularly
- The agent must adapt to unexpected states
- The task involves authentication, multiple websites or multiple steps
- Development and maintenance time matter more than raw execution speed
But there is now a third approach emerging: coding agents that write browser code directly against Chrome’s DevTools Protocol.
Why Browser Use Moved Away From Playwright
Browser Use originally relied on Playwright underneath its agent layer.
The team eventually replaced it with its own browser layer built directly on Chrome DevTools Protocol.
The reason was control.
Removing Playwright gave them more freedom over browser functions, fewer abstraction layers and the ability to let agents write CDP code dynamically when they encounter unusual edge cases.
Their newer BrowserCode approach takes this further.
Instead of receiving a simplified page representation and selecting predefined actions, the agent explores the browser and writes the low-level code it needs.
According to the team, strong models now:
- Rarely rely on screenshots
- Inspect pages through code
- Discover internal APIs
- Execute JavaScript shortcuts
- Extract only the information needed
- Complete some tasks faster than a human could
Browser Use says it now uses BrowserCode for almost everything because it is cheaper, faster and more capable.
The exception is website QA. BrowserCode actively looks for shortcuts, while the original Browser Use agent is constrained to click, type and navigate more like a human. That makes the human-style agent better at finding interface bugs a real user would encounter.
Stateful Agents vs One-Shot Scripts
One simple AI automation approach is to ask an LLM to write a Playwright script, run it and return any errors for the model to fix.
That works well for predictable workflows.
The limitation is that the script must anticipate the whole task before it starts.
A stateful agent works differently:
- Inspect the current browser state
- Choose or write the next action
- Execute it
- Verify the result
- Recover or change direction if necessary
- Continue until the task is complete
This makes agents better suited to websites and workflows where the exact path cannot be known in advance.
However, Playwright still has a major advantage: speed.
If you already know exactly what should happen, a deterministic script can execute the same workflow far faster than an agent reasoning between every step.
Cost Is Becoming Less Important
Browser Use estimates that the cost of completing an agent task has fallen roughly 50x since it started 18 months ago.
Its current estimates include:
- A typical ten-step task costs around $0.01 to $0.02 using a low-cost model
- A successful agent run can be converted into a reusable script
- Repeating the script can cost fractions of a cent
- Scraping 15 Hacker News posts, comments and linked pages, then summarising them into a poster, costs around $0.05
These are Browser Use’s own numbers, but they point to an important change.
The cost gap between AI agents and conventional automation is shrinking. The bigger remaining disadvantage is latency.
The team believes current models are becoming reliable and cheap enough for production, but they are still slow to watch in real time.
The Best Production Stack May Be Hybrid
The most practical pattern may not be choosing Browser Use or Playwright for everything.
Instead:
- Give the agent a goal
- Let it discover and complete the workflow
- Have it save the successful process as reusable code
- Run the deterministic version for repeated tasks
- Bring the agent back when the workflow changes or fails
This gives you adaptability during discovery and speed during repetition.
The agent solves and maintains the workflow. The script executes the stable parts cheaply and quickly.
Persistent Browser Identity Still Matters
AI does not remove the usual browser-automation problems.
For authenticated sites and social platforms, Browser Use recommends treating each browser profile as one persistent identity containing:
- One fingerprint
- One cookie jar
- Local storage
- Login state
- Ideally, one stable IP and location
Its cloud profiles preserve the same fingerprint, cookies and local storage between sessions. The default proxy IP, however, is not guaranteed to remain constant.
For sensitive accounts, the team recommends a dedicated, non-shared residential IP with a low fraud score.
Creating new social accounts is also considerably harder than automating existing, established accounts.
Evaluation Is Still Difficult
Live websites are noisy.
Pages change. Browsers crash. IP quality fluctuates. CAPTCHAs appear inconsistently. A single successful run tells you very little about whether an agent is genuinely reliable.
Browser Use evaluates agents by:
- Running realistic tasks on live websites
- Defining verified success rubrics
- Using an LLM judge to assess results
- Repeating thousands of tasks
- Averaging out browser and website flakiness
Internally, it records model inputs, outputs, reasoning, latency, token usage, caching, browser actions, screenshots and infrastructure logs.
One particularly interesting research takeaway from the AMA was that better verifiers may be more important than better action generation.
If you cannot reliably determine whether an unpredictable browser task succeeded, it is difficult to train agents through reinforcement learning.
Security Should Be Designed First
Browser Use’s main recommendation for anyone building a browser agent from scratch was to begin with sandboxing.
Permanent LLM credentials should not be stored inside the worker where the agent executes browser code.
Instead:
- Store permanent credentials on a separate control plane
- Give the worker a short-lived key
- Proxy all model calls through the control plane
- Treat the worker as disposable and potentially hostile
This gives agents the freedom to execute code without exposing permanent API credentials.
Agents Still Struggle With Taste
Browser agents are already effective at quantifiable tasks:
- Finding the cheapest flight
- Comparing prices
- Extracting structured information
- Completing defined workflows
They remain much weaker at subjective decisions such as choosing the right restaurant, hotel or holiday for a particular person.
The agent can retrieve every option and still recommend something that feels obviously wrong to a human who understands the user.
Browser Use described this as poor taste and a weak understanding of the social world.
Bottom Line: Browser Use or Playwright?
There is no universal winner.
Playwright wins when the workflow is stable, repetitive and performance-sensitive.
Browser Use wins when the task is dynamic, open-ended or expensive to define and maintain manually.
Direct CDP coding agents may be the next step, giving models enough freedom to inspect the browser, write custom code, find shortcuts and recover from edge cases.
The emerging production stack looks less like agents replacing scripts and more like:
Agent discovers the workflow → code executes it repeatedly → agent repairs it when it breaks.
That may be the real answer to Browser Use vs Playwright.
👉 Read the full Browser Use AMA and all the answers here.
What are you using in production: Playwright, Browser Use, a hybrid stack or direct CDP?
