Browser Use vs. AgentCore Browser: Two Managed Browsers, and Which Layer Each One Wins

TL;DR

• Two managed browsers solve the same “give an agent a browser” problem from opposite ends. AgentCore Browser is a Chromium you drive with Playwright/CDP code — no agent loop, no LLM markup, but IAM, VPC, CloudTrail, and per-session microVM isolation. Browser Use Cloud is a natural-language browser agent — you send a sentence, it runs its own loop and returns typed JSON.
• Across eleven live Browser Use experiments, the API/agent capabilities all worked first-or-second try: structured output, multi-page research, form filling, persistent profiles, deterministic rerun, a hosted MCP server, and human-in-the-loop follow-ups in one session.
• The single most valuable cost lever is deterministic rerun: run a task once (the agent builds a cached script), then replay it for $0 LLM cost. Verified — a Hacker News extraction cost $0.33 on the first run and $0.00 LLM on the second.
• The real differentiator is stealth, not intelligence. Browser Use forks Chromium to look human; their open benchmark reports 81% anti-bot bypass vs Browserbase’s 42%. I tested this on neutral bot-detection pages and it held up — bot.sannysoft.com passed 8/8 with WebDriver and headless undetected (a stock headless Chromium scores ~2%).
• The default model is the most expensive tier. Choosing claude-sonnet-4.6 over the unset default halved the cost of an identical task ($0.24 → $0.11). Model choice is a bigger cost lever than most people think, and cheaper than switching providers.

I run a fleet of autonomous agents, and some of their tasks live in a browser — a portal with no API, a vendor site that only renders data after JavaScript, a form that was never going to ship an endpoint. The practical hierarchy for agent tooling is straightforward: reach for a browser only after a native API and an existing connector are ruled out, and reach for computer use only after the browser can’t do it. This post is about the tier itself — when a browser is the right layer, which managed browser do you use?

There are two serious answers on AWS today, and they are not the same product. AgentCore Browser is the AWS-native primitive: a managed, session-isolated Chromium you connect to over CDP. Browser Use Cloud is a purpose-built browser agent: natural language in, structured data out, with a stealth-forked browser underneath. I’d already verified AgentCore Browser earlier in my work with production agent tasks. So I spent real credits putting Browser Use through eleven experiments and lined the two up on identical tasks.

The findings that surprised me: the interface gap is larger than the capability gap, the cost gap is mostly about which model not which vendor, and the thing Browser Use actually sells — stealth — is the one thing the AWS-native option doesn’t compete on.

The two browsers, by architecture

They overlap on “cloud browser” and diverge on everything above it.

The mental model: AgentCore Browser is an infrastructure primitive; Browser Use is a batteries-included agent. One gives you a governed browser to build on. The other gives you a working web agent you send a sentence to. That difference drives everything below.

What eleven experiments actually showed

I ran Browser Use Cloud through its headline capabilities. Two of them (data extraction, bot-wall detection) deliberately mirror the AgentCore Browser tasks so the two can be compared directly.

The interface win is real. On the same Best Buy extraction that took a scroll-then-innerText-then-regex Playwright script on the CDP path, Browser Use took one English sentence. That’s the whole pitch of a browser agent over a browser primitive, and it holds.

Two capabilities are worth going deeper on, because they’re where the money and the moat live.

The cost lever nobody mentions: deterministic rerun

Browser Use will run a task once with the full agent, save a standalone script that reproduces it, and then replay that script for $0 LLM cost on every subsequent run with the same shape. Caching activates when the task carries a @{{value}} marker and a workspace is attached.

I tested it on a Hacker News extraction:

The second run returned the correct data with the model never in the loop — the only cost was the browser itself. That’s the ~99% reduction the docs promise, and it turns a proven task into a near-free deterministic API. For anything you run more than once — a daily scrape, a recurring check — this matters more than which model you pick.

(One trap I hit: building the task string with Python’s str.format() collapses @{{{n}}} to @{n}, silently disabling the cache. Use an f-string and pass cacheScript=true explicitly. Verified fix.)

The differentiator is stealth — and I had the wrong read at first

Here’s where I have to correct myself in public, because it’s the most important point in the post.

My first bot-wall test was a single run against Costco. It got blocked, as did AgentCore Browser on the same site. I wrote down “neither managed browser defeats a hardened bot wall.” That conclusion was drawn from one site, one run — and it buried the single thing Browser Use is actually built around.

Because when you read what Browser Use says about itself, stealth isn’t a feature — it’s the whole thesis. Their words: “Stealth is not a feature for us. It’s the top priority.” They fork Chromium, run fully headless in a way that still looks human, and maintain in-house CAPTCHA solving. Their open benchmark reports 81% bypass vs Browserbase’s 42% — nearly double the nearest large competitor — and an independent third-party benchmark ranks them first as well. Every “Browser Use vs Browserbase” comparison in the wild frames it the same way: Browser Use is the intelligence + stealth layer; the others are infrastructure.

So a single Costco failure isn’t evidence that stealth doesn’t work — it’s evidence that one hardened Akamai/PerimeterX site can still win a given round. To test the claim properly, I ran Browser Use against neutral, purpose-built bot-detection pages — surfaces that exist specifically to measure automation detectability, so there’s no ToS line to cross and no live service being abused.

For context, Browser Use’s own control shows a stock headless Chromium scores ~2% on their benchmark and a headful one ~50%. Passing sannysoft 8/8 with WebDriver undetected is consistent with a genuinely stealthed browser. This corroborates the direction of their claim on neutral ground — I didn’t reproduce the full 81% benchmark magnitude (that’s their harness), and stealth is a cat-and-mouse spectrum, not a guarantee. But the moat is real, and it’s the reason to pick Browser Use over an AWS-native browser for external, anti-bot-heavy work.

This is the honest version of the lesson: n=1 is not a benchmark. My first read was under-powered, and the correction flips the conclusion.

One more correction, added after first publish: I later ran these same neutral pages on AgentCore Browser too (over CDP), and it passes them just as cleanly — WebDriver and headless undetected. So on neutral detection surfaces the two are level; Browser Use’s forked-Chromium moat is a bet about the hardened production gauntlet (the 71-site Akamai/Cloudflare class of target), which neither the Costco n=1 nor these neutral pages actually measure. More below.

Model choice is a cost lever, not a footnote

Browser Use bills the driver LLM at 1.2× provider rates, and if you don’t pick a model, it defaults to the most expensive tier. The API also quietly remaps model names — claude-sonnet-4.6 is served as their bu-max tier, claude-opus-4.6 as bu-ultra, and an unset model as claude-opus-4.7 (the priciest).

The same Hacker News structured-output task, identical output:

Half the cost, same result. Browser Use’s own benchmark puts Sonnet at 59% task accuracy — near Opus’s 62% — at roughly half the price, which is why it’s their recommended default too. The lesson generalizes: within a browser agent, which model is often a bigger cost swing than which vendor, and the second-biggest lever after that is bring-your-own-key (pay your provider directly + 0.2× instead of the 1.2× managed markup).

Wiring it in: the hosted MCP server

Browser Use runs a hosted MCP server, which means an MCP client — Claude Code, Cursor, or an AgentCore agent via Gateway — can call browser automation as tools without a local process. I drove it over a pure MCP JSON-RPC path: initialize → tools/list (7 tools) → tools/call, which ran run_session and returned a real answer. The server is stateless — no session ID to thread — so any client points at it with just the endpoint and an API-key header.

For an AWS-native agent, that same endpoint registers as a Gateway MCP target and the browser becomes one more governed tool alongside your APIs. That’s the clean composition path: keep the agent and its policy in AgentCore, borrow Browser Use’s stealth browser as a tool.

When to use which

It’s the same “judge the layer” discipline as the rest of this series. AgentCore Browser wins on governance and cost-at-scale. Browser Use wins on time-to-working-agent and on the one capability AWS doesn’t sell: defeating bot detection.

What’s missing

Two honest notes — one gap closed, one gap that stays open by design.

The stealth head-to-head — now run, and it corrected my prior. I originally shipped this with only the Browser Use side measured and hedged that “AgentCore Browser is weaker on stealth” as a prior from architecture (standard Chromium vs a forked one). I’ve since run the AgentCore side on the same neutral pages — attaching Playwright to the managed AgentCore Browser over CDP and reading each detection page’s own verdict. The prior was wrong on these surfaces. AgentCore Browser passes bot-detection checks with zero genuine automation flags, and CreepJS reports it cleanly — the same result Browser Use gets. The one consistent AgentCore tell is a GPU/WebGL capability gap (“no WebGL context” — the per-session microVM has no GPU), which is a rendering limitation, not a bot signal. So on neutral bot-detection pages, the two are level. Where Browser Use’s forked-Chromium moat would actually separate is the adversarial 71-site production gauntlet (Akamai/PerimeterX/Cloudflare) — and that I still haven’t run; the neutral pages don’t stand in for it.

The paid-claim capabilities are untested by design. CAPTCHA-defeat on live services and 2FA/TOTP handling both need a sensitive target I won’t automate in a public experiment. Browser Use’s in-house CAPTCHA solver and their full 81% benchmark magnitude remain their numbers, corroborated in direction but not reproduced end-to-end.

So what

If you’re on AWS and the browser is one tool inside a governed agent, use AgentCore Browser — you get the browser as a first-class, IAM-scoped, VPC-private, microVM-isolated primitive, and you pay Bedrock directly with no markup. If your problem is reaching external sites that fight automation, use Browser Use — that’s the whole reason it exists, and the stealth benchmark backs it.

And carry the one methodological lesson out of here even if you never touch either product: a single site, a single run, is not a benchmark. I concluded “stealth doesn’t work” from one blocked Costco page, and the properly-powered test flipped it. The vendor whose entire moat is stealth turned out to have a moat. Test the claim on the surface built to measure it, not on the first hard site you happen to hit.

Related reading: Four Tools, One Loop: The AgentCore Knowledge Worker, The AgentCore Map.