Why Scripted Browsers Refuse to Stay Scripted
A form changed its field order last month. One CSS class got renamed. The scraper my team runs against a supplier portal had been working for eleven months, and then it wasn’t. The fix took nine minutes, but the outage sat in a Slack thread for two days before anyone noticed.
Disclosure: This article contains affiliate links. If you buy through one of them, this site may earn a commission at no extra cost to you.
That small failure is the whole argument for AI browser agents. When the steps are known and stable, a scripted tool wins on speed and price. When the page drifts, someone has to babysit the script. AI agents trade a bit of predictability for the ability to look at a page and figure out where the button went.
Below I compare the three approaches you’ll actually encounter in 2026: Playwright as the deterministic base layer, Browser Use as the agent-first library, and Stagehand as the hybrid that sits on top of Browserbase. Pricing comes from vendor pages as of October 21, 2026. I did not run a formal benchmark on all three, and I’ll say plainly which claims come from my own work and which come from documentation.
The Short Answer, If You’re in a Hurry
- You know the steps and they rarely change: Playwright. It’s free, it’s open source, and it doesn’t burn tokens deciding which link to click.
- You want an agent to figure out the steps: Browser Use. It’s the most popular open-source option and the hosted version is metered by the minute.
- You want agents that learn a workflow and then run it cheaply: Stagehand. The action cache is the feature nobody else sells the same way.
Comparison Table: What Each One Costs
| Tool | Type | Entry price | What you pay for inference | Best fit |
|---|---|---|---|---|
| Playwright | Open-source library | Free (Apache 2.0) | Nothing, unless you attach an LLM | Tests, scrapers, fixed workflows |
| Playwright MCP | MCP server (free) | Free | Your coding assistant’s own token bill | Letting an assistant drive a real browser |
| Browser Use (library) | Open-source agents | Free (MIT) | Your model provider, per task | Prototypes where steps are unknown |
| Browser Use Cloud | Pay as you go | $1 free credit, $5 minimum top-up | Model cost + 20% markup | Agents that need stealth or proxies |
| Browserbase / Stagehand | Managed browsers + SDK | Free tier, Developer $20/mo | Your model key, minus cache hits | Production agents on many sessions |
Numbers above are from browser-use.com/pricing and docs.browserbase.com as of October 21, 2026. Browser infrastructure rates shift often, so check the vendor page before you budget. Browser Use charges $0.02 per browser-hour and $5 per GB of residential proxy traffic, with direct or bring-your-own proxy at $0.20 per GB.
Playwright: The Boring Base Layer That Still Wins
I’ve had Playwright in my own stack for a while, and it’s the tool I reach for first. One API drives Chromium plus Firefox and WebKit, and it ships with bindings for TypeScript, Python, Java, and .NET, documented at playwright.dev. The Python package is at version 1.64.0 on PyPI under an Apache 2.0 license. Installation is two commands, and then you’re writing selectors.
What I like: it’s fast, the traces are genuinely useful when a test fails, and it costs nothing per run. A hundred daily regression runs cost the same as one.
What I don’t love: every selector is a promise that the page structure won’t change. The library can’t infer intent. If a button moves from a link to a div, your test fails loudly, which is correct behavior for tests and miserable behavior for scraping at scale.
The interesting 2026 development is Playwright MCP, which hands the same browser engine to an LLM through structured accessibility snapshots rather than screenshots. The project on GitHub has roughly 38,000 stars and releases often. In practice this is the cheapest way to let a coding assistant poke at a local page: no vision model, no image token bill, just the accessibility tree. Community writeups in 2026 have argued the CLI form is considerably more token-efficient than the MCP form, which tracks with my experience with MCP servers in general. Every tool you expose becomes context.
Browser Use: Agents Without a Script
Browser Use is an open-source Python library where you describe a task in plain language and the agent decides the clicks. The GitHub repo sits around 118,000 stars under an MIT license, which makes it the default starting point for anyone prototyping in this category.
On cost, the library itself is free and you pay your model provider directly. The hosted service is pay as you go with a $1 free credit and a $5 minimum top-up, billed at $0.02 per browser-hour plus model cost at a 20% markup. Credits don’t expire. Concurrency starts at 10 sessions and climbs with total spend: $1,000 unlocks 250, $5,000 unlocks 500. Those tiers matter if you plan to run a lot of sessions in parallel.
Here’s the honest downside. Agent runs are variable. The vendor’s own benchmark table lists per-task costs ranging from a few cents on a fast model up to several dollars on a frontier one for hard tasks, and their note says those recorded figures exclude judging and hosting along with some calls, so treat them as a floor. If your automation fires 500 times a day and the agent decides to think for 30 seconds each time, the bill is not the $0.02 browser rate. It’s the model.
Run the math on a realistic month and the gap gets uncomfortable. Five hundred runs a day at even $0.15 per task is roughly $2,250 monthly, against a Playwright script that costs you the electricity for a spare mini PC. That comparison is unfair to the agent, since it can handle pages a script can’t, but it’s the number a finance person will ask about.
My rule of thumb: use Browser Use to discover a workflow, then port the workflow into Playwright once you know the steps. You keep the intelligence for the exploration and the determinism for the daily grind.
Stagehand and Browserbase: Where the Meter Actually Runs
Stagehand is Browserbase’s SDK. It wraps the same idea, natural-language actions over a real browser, but adds a detail that changes the economics: it caches the results of repeated act(), observe(), and extract() calls server side. When the page structure is one it has already seen, the cached result comes back without an LLM call. Since Browserbase manages the cache, there’s no file to ship or invalidate yourself.
That’s the closest thing in this space to a real cost fix. Agents are expensive because they re-reason about the same page every run. Caching converts the tenth run into something closer to a script.
Browserbase pricing is a subscription with an allocation: Free at $0 with 1 browser-hour and 3 concurrent sessions, Developer at $20 for 100 hours and 25 sessions, Startup at $99 for 500 hours and 100 sessions. Overage runs $0.12 per hour on Developer and $0.10 on Startup. Free-tier sessions cap at 15 minutes, while paid tiers allow 6 hours. If you need Verified identity or HIPAA paperwork, that’s the custom Scale plan.
The catch: the free tier’s single browser-hour disappears quickly when you’re debugging. One long session with retries and you’re over. Budget the Developer tier on day one rather than treating free as a real option.
How I Evaluated These Three
Let me be specific, because affiliate programs do read this part.
I use Playwright regularly in my own work, so that section reflects real use, including the renamed-selector incident at the top. For Browser Use and Stagehand I read the vendor pricing pages and GitHub repos, along with the documentation and several third-party comparisons published this year. I did not run a head-to-head benchmark of agent success rates, and I’m not going to pretend otherwise. Where a number appears, I’m citing the vendor’s own page and the date I read it.
A few things I couldn’t verify and therefore haven’t quoted: per-task success-rate claims that only appear on a vendor blog, and any “X% cheaper” figure that doesn’t show the workload behind it. Those numbers move too fast to be useful in a buying decision anyway.
Which One Should You Actually Pick?
If your problem is testing, none of the agent tools are the answer. Playwright is free and faster, and your CI pipeline already knows how to fail on it. Adding an LLM to a test suite mostly adds flakiness.
If your problem is scraping a site that redesigns itself, start with Browser Use in library form. Point it at the page with your own model key, let it find the data, then write down what it did. Move that into Playwright. You’ll spend a few dollars on tokens once and nothing after that.
If your problem is running an agent in production across many sessions, Stagehand is the more grown-up option. The cache matters, the concurrency is real, and the metering is predictable enough to put in a spreadsheet. You’re paying $20 to $99 a month for infrastructure, not for results, so keep your model costs separate.
And if your problem is letting a coding assistant see a page, the Playwright MCP server is the cheapest path that works. Install it, point your editor at it, and stop describing your markup to the model.
Three Traps I’d Avoid
- Mixing agents into scheduled jobs. If a task runs on a cron and the agent decides to do something unexpected, nobody’s awake to catch it. Keep agents in jobs a human can watch.
- Assuming browser hours are the bill. The $0.02 rate is the cheapest line item on a Browser Use invoice. Model inference dwarfs it.
- Wiping the cache every deploy. Stagehand’s savings come from repetition. If your CI clears cache state each time, you’re paying full LLM price for the same page you saw yesterday.
Frequently Asked Questions
Is Playwright really free for commercial use?
Yes. It’s Microsoft-maintained and released under Apache 2.0, so you can use it commercially with no per-run fee. You’ll pay for the machines you run it on.
Can I run Browser Use without paying for cloud hosting?
Yes. The MIT-licensed library runs against a local browser. You only need the cloud service if you want stealth browsers, residential proxies, or managed concurrency.
Do AI browser agents work on sites with login walls?
Sometimes, and inconsistently. Sessions and cookie handling are where most failures happen in reports I’ve read, with two-factor flows the usual culprit. Budget testing time for any authenticated workflow.
The Bottom Line
Most teams don’t need to choose one. The arrangement that has worked for me is layered: an agent for figuring out where things are, a cache to stop the agent from re-deciding, and a plain Playwright script for the thing that runs every hour. The agent is the discovery tool. The script is the worker.
Where Each Tool Fits Six Months From Now
One more thought on longevity, because these tools change faster than the pages they automate. Playwright will still be here. It’s backed by a large engineering org, it has become the default for end-to-end testing, and its MCP server means it gets to ride whatever assistant wave comes next.
Browser Use and Stagehand are riskier bets, not because the products are weak but because the category is crowded. Browserbase’s own comparison page lists seven competitors offering cloud browsers for agents. Pricing at that layer is a race downward, and features get copied within a quarter. If you build your production pipeline on either one, keep the browser control behind your own thin abstraction so a price change doesn’t mean a rewrite.
If you’re starting today and want the cheapest path to results, install Playwright and add the MCP server to your editor. Tests and scraping both run on it for zero dollars in software cost, and your assistant gets a browser in the same move. Graduate to Browser Use when the pages stop cooperating, and to Stagehand when you need the same agent running 50 sessions at once.
Next step: pick one workflow you currently babysit by hand and rewrite it as a Playwright script this week. You’ll learn more from that hour than from any comparison table, including this one.
Pricing and product details verified against vendor pages on October 21, 2026. Some links on this site are affiliate links; they don’t change what you pay.