Rex runs 30 real browser automation workflows — flight booking, tax forms, paywalled reports, Notion migrations — through three frameworks and publishes success rates and failure patterns that the README demos will never show you.
What I Was Testing and Why
Browser control is the capability that unlocks AI agents actually doing things on the web. Not just reading pages — booking, submitting, filling, navigating. The three main approaches right now are meaningfully different architecturally and the benchmark numbers people post online are almost always cherry-picked demos.
I built a test suite of 30 workflows I would actually want automated. Things a real person does on a real computer. No toy tasks.
The workflow categories:
• Transactional (10): Book a flight, reserve a restaurant, file a USPS change-of-address, submit a government permit application, buy a specific product on Amazon
• Data extraction (8): Scrape a report behind a soft paywall, extract a table from a government statistics page, pull all invoice amounts from an email-connected billing portal
• Migration/bulk (7): Move 50 rows from a Google Sheet into a Notion database, bulk-download invoices from a SaaS billing portal, add contacts from a CSV into LinkedIn
• Form completion (5): Fill a multi-page IRS form with structured data, complete a state business registration, submit a building permit application
The three frameworks:
• Playwright MCP Server (Microsoft, v1.1.0) hooked to Claude 3.7 Sonnet via MCP
• Browser-Use (v0.1.40) with GPT-4o as the agent model
• Anthropic Computer Use with Claude 3.7 Sonnet (screenshot-based, not DOM-based)
Success criterion: the workflow completed its stated goal without requiring manual intervention. Partial credit given for workflows that completed the main goal but left a minor step incomplete (e.g., got to checkout but didn't click "confirm").
Methodology
For Playwright-MCP I ran the official Microsoft MCP server and connected it to Claude via the Anthropic API with tool use:
# Playwright-MCP evaluation harness
import anthropic
from mcp import ClientSession,
StdioServerParameters
from mcp.client.stdio import stdio_client
async def run_playwright_task(task: str) ->
dict:
server_params = StdioServerParameters(
command="npx",
args=["@playwright/mcp@1.1.0", "--headless"]
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
tools = await session.list_tools()
client = anthropic.Anthropic()
messages = [{"role": "user", "content":
task}]
# Agentic loop with 25-step limit
for step in range(25):
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
tools=[format_mcp_tool(t)
for t in tools.tools],
messages=messages
)
# ... tool execution and loop logic
|
For Browser-Use I used its Python API directly:
# Browser-Use evaluation (v0.1.40)
from browser_use import Agent
from langchain_openai import ChatOpenAI
async def run_browser_use_task(task: str)
-> dict:
agent = Agent(
task=task,
llm=ChatOpenAI(model="gpt-4o"),
max_actions_per_step=10,
generate_gif=False # disable
for speed
)
result = await agent.run(max_steps=30)
return {"final_result": result.final_result(),
"n_steps": result.n_steps()}
|
Computer-Use ran through Anthropic's computer use API with a real Chrome instance in a Docker container. This is the only screenshot-based approach — it sees pixels, not DOM.
Results
Full success rates by category:
Transactional (10 tasks): Playwright-MCP 60% · Browser-Use 50% · Computer-Use 30%
Data extraction (8 tasks): Playwright-MCP 62% · Browser-Use 62% · Computer-Use 50%
Migration/bulk (7 tasks): Playwright-MCP 43% · Browser-Use 43% · Computer-Use 43%
Form completion (5 tasks): Playwright-MCP 40% · Browser-Use 20% · Computer-Use 60%
Overall: Playwright-MCP 52% · Browser-Use 47% · Computer-Use 41%
Mean time to completion: Browser-Use 1:40 · Playwright-MCP 2:10 · Computer-Use 4:20
The partial-success story is interesting: add 15-22 percentage points to all three if you count "completed the main goal with one step short." The most common partial-success pattern is getting to a confirmation screen and not clicking the final submit button — seems to be a trust/caution behavior baked into all three backing models.
Failure Modes
Playwright-MCP fails hardest on dynamic SPAs where the DOM changes after interaction. It has excellent structural understanding of static HTML but React/Next.js apps that re-render on every state change confuse its selector logic. I watched it successfully fill a form, trigger a re-render that subtly changed a button's data-testid, and then fail to find "the button it just clicked" to confirm. Version 1.1.0 has improved this vs earlier releases but it's still the Achilles heel.
Browser-Use is fast and capable but over-clicks. Its action model generates more actions per task than the other two (mean 18 vs 11 for Playwright-MCP) which means more surface area for errors to compound. It also struggles with CAPTCHAs — it attempts them, sometimes successfully, but the solve rate on hCaptcha was 20%. reCAPTCHA v3 it handles reasonably since it's score-based, not interactive.
Computer-Use is the most human-like but the slowest, and the screenshot pipeline adds real latency. Its p95 completion time of 4:20 is painful for tasks a human would do in 45 seconds. Where it actually wins is on form completion — it scored 60% vs 40% for Playwright-MCP on that category. Forms with unusual layouts, custom UI components, or accessibility overlays that confuse DOM-based approaches are no obstacle to a pixel-level observer.
All three fail on multi-factor authentication. If your workflow requires a TOTP code or SMS verification mid-stream, plan for human handoff.
What I Would Actually Deploy
For structured web automation on modern SPAs: Playwright-MCP is the clearest production path. The Microsoft team is actively maintaining it and the MCP interface means you can swap underlying models as they improve.
For quick-and-dirty automation on consumer sites: Browser-Use is faster to ship and faster to run. The 5-point solve rate difference vs Playwright-MCP doesn't matter if you're building something where partial success is acceptable.
For workflows involving unusual UIs or legacy web forms: Computer-Use. It's expensive and slow but it can handle things the others literally cannot see.
My actual deployment: a tiered system that tries Browser-Use first (cheapest/fastest), escalates to Playwright-MCP on first failure, and pages a human after the second failure. End-to-end solve rate in production testing: 71% fully automated, 29% human-assisted.
Repo / Gist Coming
The full 30-task test suite with pass/fail logs and the tiered routing harness will be in the repo. Also: the synthetic task runner that generates believable form data for testing without hitting real services.

Figure 3. Grouped horizontal bar chart with three frameworks (Playwright-MCP, Browser-Use, Computer-Use) broken out by task category (Transactional, Extraction, Migration, Form). Success rate % on x-axis. Da…
REFERENCES
1. Playwright MCP Server — Microsoft. Microsoft / GitHub (2026).
https://github.com/microsoft/playwright-mcp
2. Browser-Use — Open-Source Web Agent Framework. Browser-Use GitHub (2026).
https://github.com/browser-use/browser-use
3. Anthropic Computer Use Documentation. Anthropic (2026).
https://docs.anthropic.com/en/docs/build-with-claude/computer-use
4. Model Context Protocol Specification. Anthropic / MCP (2025).
https://spec.modelcontextprotocol.io/
5. Playwright Documentation — Selectors and Locators. Microsoft Playwright (2026).
https://playwright.dev/docs/selectors
6. OpenAI GPT-4o System Card. OpenAI (2024).
https://openai.com/index/gpt-4o-system-card/
7. WebArena: A Realistic Web Environment for Building Autonomous Agents. arXiv (2023).
https://arxiv.org/abs/2307.13854



Comments (0)
Join the conversation!