cd /news/developer-tools/why-playwright-mcp-cost-us-5-more-to… · home topics developer-tools article
[ARTICLE · art-43826] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

Why Playwright MCP Cost Us 5 More Tokens Than We Expected

An open-source browser automation MCP called Brocogni reduces token costs by 81% compared to Playwright MCP by pre-computing selectors server-side. The developer found that iteration, not observation quality, drives costs when generating reusable Playwright scripts. Brocogni returns only actionable elements with pre-computed selectors, eliminating the need for LLM reasoning about ephemeral references.

read3 min views1 publishedJun 29, 2026

We built an open-source browser automation MCP because we wanted something simple:

Observe a webpage once, let an LLM interact with it, then export a Playwright script that actually works.

That sounds straightforward.

It wasn't.

While benchmarking against Playwright MCP, we discovered something we hadn't considered: observation quality isn't the biggest contributor to cost. Iteration is.

The expensive part isn't making the browser agent click buttons.

It's making the generated automation reusable.

browser_snapshot

Playwright MCP represents elements using ephemeral references:

button "Login" [ref=e5]
textbox "Email" [ref=e10]
link "Forgot password" [ref=e23]

Within an MCP session, this is excellent.

The model simply responds:

browser_click("e5")

Fast.

Clean.

Minimal reasoning.

The problem appears later.

Every snapshot generates a new set of references.

e5

today is not e5

tomorrow.

Those identifiers only exist for the lifetime of that observation.

Many people aren't using browser agents just to click around.

They're using them to produce reusable automation.

For example:

Once the LLM tries to generate code like this:

await page.getByRole(...);

the references become useless.

They're meaningless outside the MCP session.

The model now has to reconstruct selectors from scratch.

That usually means:

The browser interaction itself is cheap.

The retries are not.

Instead of measuring a single observation, we measured the full pipeline:

Observe
    ↓
Interact
    ↓
Generate Playwright Script
    ↓
Execute Script
    ↓
Fix Failures if Needed

The numbers were surprising.

≈ 1,099 tokens

getByRole()

selectors≈ 1,171 tokens

≈ 941 tokens

3,211 tokens
≈ $0.04 per generated script

Instead of returning references, Brocogni computes selectors before the LLM ever sees the page.

The observation already contains:

The model simply copies them into the Playwright script.

One observation.

One generation.

Done.

1,535 tokens
≈ $0.01 per generated script

Across roughly 200 generated scripts/month:

Solution Monthly Cost
Playwright MCP ~$7.11
Brocogni ~$1.33

That's roughly an 81% reduction in token cost in our benchmark.

More importantly, it's fewer failed iterations.

Another observation was how much unnecessary information reaches the LLM.

A typical Playwright MCP snapshot contains:

Only around 9 are actually interactive.

The model must determine:

That reasoning consumes tokens.

Brocogni instead returns only actionable elements.

Playwright MCP Brocogni
Elements returned 62–93 9
Actionable Mixed 9/9 (100%)
LLM filters nodes Yes No
Pre-computed selectors No Yes
Fallback selector chains No Yes

The observation is slightly richer.

The downstream reasoning becomes dramatically simpler.

The distinction comes from where the work happens.

Playwright MCP exposes browser state.

The LLM performs much of the interpretation.

Brocogni shifts that interpretation server-side.

Chrome DevTools Protocol
          │
          ▼
Accessibility Tree
          │
          ▼
DOM Snapshot
          │
          ▼
Geometry Extraction
          │
          ▼
Actionability Filtering
          │
          ▼
Purpose Inference
          │
          ▼
Ranked Selector Generation
          │
          ▼
Structured JSON Observation
          │
          ▼
LLM

By the time the model receives the observation:

The LLM doesn't need to reverse-engineer the DOM.

Playwright MCP is extremely well designed for interactive browser agents.

If your goal is simply:

"Navigate a website."

it's an excellent choice.

Our benchmark looked at a different workflow:

"Generate Playwright code that someone will commit to a repository."

Those are different optimization problems.

For the second case, reusable selectors matter more than ephemeral references.

Brocogni is an open-source MCP server focused on browser automation for LLMs.

Instead of exposing raw browser state, it provides structured observations that are immediately usable for automation generation.

GitHub

https://github.com/hrshx3o5o6/brocogni

Website

I'd love feedback from people building browser agents or using Playwright MCP in production.

If you've measured similar token costs—or found different tradeoffs—I'd be interested to compare approaches.

── more in #developer-tools 4 stories · sorted by recency
── more on @playwright mcp 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/why-playwright-mcp-c…] indexed:0 read:3min 2026-06-29 ·