---
title: "Browser Use vs. AgentCore Browser: Two Managed Browsers, and Which Layer Each One Wins"
description: "AgentCore Browser gives an agent a governed browser inside your AWS account. Browser Use Cloud gives it a natural-language browser with a stealth moat. I ran eleven live experiments against Browser Use — extraction, structured output, profiles, deterministic rerun, MCP, human-in-the-loop, and a stealth benchmark — and put it head-to-head with AgentCore Browser on identical tasks. The interface, the cost, and the differentiator are not where the marketing points."
canonical_url: "https://artificialcuriositylabs.ai/posts/browser-use-vs-agentcore-browser/"
md_url: "https://artificialcuriositylabs.ai/posts/browser-use-vs-agentcore-browser.md"
published_at: "2026-07-17T07:00:00.000Z"
tags:
  - "agents"
  - "agentcore"
  - "bedrock"
---

## 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.

| Dimension | AgentCore Browser | Browser Use Cloud |
|---|---|---|
| Interface | Playwright / CDP code you write | Natural-language task → JSON |
| Agent loop | You build it (Strands, LangChain) | Built in, model-driven |
| Structured output | Parse it yourself | Native JSON schema |
| Stealth | Standard managed Chromium | Forked Chromium, headless-that-looks-human |
| LLM cost | None — you call Bedrock at 1.0× | 1.2× managed markup, or bring-your-own-key + 0.2× |
| Enterprise envelope | IAM, VPC/PrivateLink, CloudTrail, HIPAA/FedRAMP | SOC 2 |
| Isolation | per-session microVM | managed |

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.

| Capability | Result |
|---|---|
| Data extraction (lazy-loaded prices) | Extracted Best Buy prices from a sentence — no scroll/wait/regex code, which the CDP path needs |
| Structured output (typed JSON) | Returned schema-conforming JSON via a `save_output_json` tool call |
| Multi-page research | Synthesized pricing + a feature from two vendor sites in one task |
| Form filling (RPA) | Filled a form's fields and respected "do not submit" |
| Persistent profiles | Wrote a marker in session 1, read it back in session 2 via the same profile |
| Deterministic rerun | Cached script replayed at **$0 LLM cost** |
| Hosted MCP server | 7 tools; a live `tools/call` ran a task end-to-end over MCP |
| Human-in-the-loop | Two tasks in one kept-alive session, browser state shared |
| Stealth | Passed neutral bot-detection pages (see below) |

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:

| Run | What happened | LLM cost | Total | Steps |
|---|---|---|---|---|
| 1 | Full agent explored, built and saved the script | $0.3277 | $0.3277 | 3 |
| 2 | Same template, new parameter — replayed the cached script | **$0.00** | $0.0003 | 0 |

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.

| Test page | Loaded | WebDriver detected | Headless detected | Verdict |
|---|---|---|---|---|
| bot.sannysoft.com | ✅ | ❌ no | ❌ no | **8/8 checks passed** |
| CreepJS | ✅ | ❌ no | ❌ no | fingerprint computed, ~31% headless-like (low) |
| browserleaks (canvas) | ✅ | ❌ no | ❌ no | unique signature, no automation flag |

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:

| Model | Served as | Cost |
|---|---|---|
| *(unset default)* | claude-opus-4.7 | $0.24 |
| `claude-sonnet-4.6` | bu-max | **$0.11** |

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

| Situation | Reach for |
|---|---|
| The browser is one governed tool inside a production AWS agent | AgentCore Browser (IAM, VPC, CloudTrail, microVM) |
| External scraping/RPA against anti-bot-heavy sites | Browser Use (stealth moat) |
| You want a working web agent from a sentence, fast | Browser Use |
| You need no LLM markup and full control of the loop | AgentCore Browser + your own Bedrock calls |
| A task you'll run many times | Either — but Browser Use's deterministic rerun makes repeats ~free |
| Regulated data that can't leave your network | AgentCore Browser (VPC-private) |

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](https://artificialcuriositylabs.ai/posts/agentcore-knowledge-worker-four-tools/), [The AgentCore Map](https://artificialcuriositylabs.ai/posts/the-agentcore-map/).