The agent browser stack: browser infrastructure vs browser agent framework

Three different products are sold under the word "browser" to people building agents, and the fastest way to make a bad architecture decision is to treat them as competitors. A browser agent framework decides what happens next on the page. Browser infrastructure runs the browser process and bills you for it. A scraping browser is a remote Chromium endpoint bundled with proxies, sold by the proxy industry and metered on bandwidth. The first two are orthogonal choices that you make separately and combine. The third is not a cheaper version of either.
The confusion is structural, not accidental. Review coverage of "scraping browsers" comes out of the proxy market, so it ranks products whose primary unit is an IP pool: Bright Data, Oxylabs, Decodo and their peers, none of which appear in serp.fast's directory. The agent-runtime vendors do not show up on those lists because they do not sell proxies as the headline product. Meanwhile the framework side of the search results is dominated by vendor-authored comparisons: two of the most visible "Browser Use vs Stagehand" and "Browserbase vs Stagehand" write-ups are published by Skyvern and both end by recommending Skyvern. Neither corner of the market has an incentive to tell you the two decisions are independent.
They are independent because of a protocol detail. Browser Use, Stagehand, Skyvern and plain Playwright all drive a browser over the Chrome DevTools Protocol, and every managed runtime in the category exposes a CDP endpoint. Swapping the runtime is a connection-string change plus some vendor-specific glue. Swapping the framework is a rewrite of your agent logic but touches nothing about where the browser runs. Conflating them means you run a shortlist against one axis and never notice there were two.
Three products, one word
| Product | What you are buying | Primary meter | Typical vendors |
|---|---|---|---|
| Agent browser | Session lifecycle for a model-driven run: persistence, live view, replay, human handoff, declared identity | Browser-hours plus concurrency | Browserbase, Steel.dev, Kernel, Anchor Browser, Hyperbrowser, Airtop |
| Scraping browser | A Chromium endpoint that gets pages to load under hostile detection, bundled with a residential IP pool | Bandwidth (GB) | Proxy-first vendors, not in this directory |
| Test browser | Deterministic parallel execution of scripted flows across engines and viewports | Concurrent browsers and session-minute caps | Browserless, self-hosted Playwright grids |
The lineages are different too. Test browsers are the oldest: Browserless has run headless Chrome as a service since 2017, and its published plans still meter the two things a CI system cares about, concurrent browsers and maximum session time (its Prototyping tier lists 10 concurrent browsers and a 15-minute session cap, Scale lists 100 and 60 minutes). Scraping browsers grew out of proxy networks around 2022. Agent browsers are the 2024-onward category, and they are the only one designed around a session that a language model steers for minutes or hours and that a human may need to look at while it runs.
Consumer AI browsers are a fourth thing entirely and not a substitute for any of the above. OpenAI is retiring the standalone Atlas browser; its own help center gives 9 August 2026 as the date Atlas stops working, and Search Engine Land reported the same date from OpenAI's James Sun, with browser-based agentic work folding into the ChatGPT desktop app. PPC Land framed the same change as Atlas and Codex collapsing into a single ChatGPT interface. Reporting on the sunset also mentions a cloud browser for agents arriving alongside it; that is reported, not something you can buy against today.
Axis one: who owns the control loop
The first real decision is who picks the next action. There are three answers, and they trade predictability against tolerance for unfamiliar pages.
A script decides. Playwright or Puppeteer with selectors you wrote. Deterministic, fast, free of model cost, and the correct answer for any flow you control or that changes rarely. It breaks the day the site redesigns, and it cannot handle a page it has never seen.
A framework decides, with a model consulted per step. Stagehand's act, extract and observe primitives sit over the browser and resolve a natural-language instruction into a concrete action, with the option to cache the resolved action so repeat runs decay toward script speed. Stagehand v3, released February 2026, was rewritten to talk to the browser directly over CDP rather than through an automation layer. This is the middle position: the model is in the loop for resolution, not for planning.
A model owns the loop. Browser Use hands the model a DOM snapshot with indexed elements and lets it choose actions until the task is done or the budget runs out. Skyvern does the same thing vision-first, working from screenshots, which is what makes it comparatively resilient to DOM churn and comparatively expensive per step. Native computer-use models from the frontier labs are the same shape with the framework folded into the model.
| Control loop | Handles unseen pages | Cost per step | Fails by |
|---|---|---|---|
| Script (Playwright, Puppeteer) | No | Zero model cost | Selector breaks silently on redesign |
| Framework-mediated (Stagehand) | Partially | One resolution call, cacheable | Ambiguous instruction resolves to the wrong element |
| Model-owned (Browser Use, Skyvern, native CUA) | Yes, unreliably | Full snapshot or screenshot per step | Loops, or completes the wrong task confidently |
Vendor-published numbers on this axis should be read as directional. Skyvern reports 64.4% on WebBench, a 5,750-task benchmark it built and publishes itself, and 85.8% on WebVoyager. Firecrawl's roundup cites Browser Use at 89.1% on WebVoyager. Steel's leaderboard index lists Browser Use Cloud at 97.0% on Online-Mind2Web and two Stagehand configurations at 65.0% and 55.0%, all self-submitted by the vendors in March 2026. Different harnesses, different models, different submission dates. The ranking is not comparable across rows; the shape is: DOM-driven loops on familiar consumer sites do well, and everything falls apart on longer transactional work.
Axis two: where the browser process runs
The second decision has nothing to do with the first. It is an infrastructure question about session length, concurrency, cold-start latency and who carries the operational burden.
Local or self-hosted. Playwright on your own machines. No per-session fee, full control over extensions and binaries, and the whole operational cost of running Chromium fleets. Lightpanda is the interesting variant here: an AGPL browser written from scratch in Zig that executes JavaScript and exposes CDP but omits layout, image decoding and rendering entirely. Its own published benchmark, running 933 real pages on an AWS m5.large at 25 parallel tasks, reports 123MB of memory against Chrome's 2GB and a 5-second crawl against 46 seconds. The tradeoff is in the omissions: no screenshots, partial web API coverage, so it suits high-volume text extraction and not vision-driven agents.
Managed sessions. The agent-browser vendors. You request a session, get a CDP endpoint, and pay for wall-clock time. Browserbase's published July 2026 ladder is Free (1 browser-hour, 3 concurrent), Developer at $20/month (100 hours, 25 concurrent, then $0.12 per browser-hour), Startup at $99/month (500 hours, 100 concurrent, then $0.10), and custom Scale at 250+ concurrent. Hyperbrowser publishes a flat $0.10 per browser-hour with credits at $0.001 each. Airtop's published July 2026 plans run from a free tier through Starter at $26/month to Enterprise at $502/month with SOC 2 Type 2. Steel.dev is the open-source option, self-hostable when you would rather not meter at all, and its own published session-start comparison puts it under a second where it measured Hyperbrowser in the multi-second range. Kernel takes a different architectural bet, running browsers as unikernels for fast cold starts with standby sessions that persist for hours and native MCP support.
Hyperscaler and edge rendering. Cloudflare's Browser Rendering is the notable one, and it matters less for its pricing than for its position: Cloudflare has been sending signed Web Bot Auth headers from its own rendering product, which places it inside the identity regime described below.
For the full vendor-by-vendor selection on this axis, including the cases where you should skip browsers entirely, see the cloud browser infrastructure guide. This guide is about how that choice interacts with the framework choice, which is a question that selection does not answer.
Why the axes are orthogonal, and what conflating them costs
Because CDP is the shared interface, you can change one axis without touching the other. Most buying processes assume the opposite, and that assumption gets expensive in three specific ways.
You buy a framework to solve an infrastructure problem. A team hits session instability at concurrency, concludes the agent framework is unreliable, and migrates from Browser Use to a vendor-managed agent product. The instability was concurrency ceilings and session-time caps on the runtime plan. Migrating the framework rewrote the agent and left the ceiling in place.
You buy infrastructure to solve a control-loop problem. An agent fails on unfamiliar checkout flows, so the team upgrades to a premium browser runtime with better stealth. Stealth was not the failure mode. The model could not decide which of two "Continue" buttons committed the order, which is the failure mode ClawBench was built to expose.
You lock the two together and cannot price either. Bundled per-step pricing (Skyvern's cloud, Hyperbrowser's $0.02 per agent step) is genuinely simpler to forecast, and it is the right call for a team that does not want three invoices. It also means you can no longer answer "would a cheaper runtime fix this bill" or "would a different loop halve the steps," because you have one number instead of two.
The one place the axes genuinely couple is anti-bot posture, covered below, because identity is a property of the session and therefore of the runtime, while the behavior that triggers detection is a property of the loop.
Production session features nobody demos
Once you are past the prototype, the features that decide the vendor are not the ones on the landing page.
Session replay. A recording of the trajectory, not just logs. When an unattended agent does the wrong thing on a live site, the postmortem is impossible without one. ClawBench's methodology is instructive here: it grades runs using five layers of recorded behavior, including screenshots, HTTP traffic, reasoning traces and browser actions, precisely because completion alone does not tell you why a run failed.
Live view and human handoff. A real-time embed of the running session that a person can take control of. Given the completion rates ClawBench and OSWorld 2.0 report, this is the feature that makes an unreliable agent shippable at all: a run the model cannot finish becomes a queue item for a person instead of a silent wrong action on a live site. It is also the clearest structural difference between an agent browser and a test browser: CI never needs a human in the loop.
Raw CDP access. Vendors that only expose their own SDK cannot run your existing Playwright code, your custom network interception, or a framework they have not partnered with. Raw CDP is what keeps the axes orthogonal, and it is worth confirming rather than assuming.
Session persistence and standby. Whether a session survives across hours and how it is billed while idle. Kernel's standby mode and Browserbase's session data retention windows are the same requirement solved differently, and both matter for agents that wait on a human, an email confirmation, or a slow backend.
What the benchmarks report, and who published them
Two 2026 benchmarks changed what a realistic completion estimate looks like, and both are worth reading for their methodology rather than their leaderboard.
ClawBench, from the NAIL Group at TIGER-AI-Lab (arXiv 2604.08523, April 2026), runs 153 everyday tasks across 144 live production sites in 15 categories, deliberately weighted toward write-heavy, state-changing work: purchases, appointments, job applications, long forms. Rather than sandboxing the sites, it uses a Chrome extension plus a CDP instrumentation server to intercept the single final HTTP request that would commit an irreversible transaction. The published headline is that the best of seven frontier models completed 33.3% of tasks, with the rest of the suite trailing well below that. Steel's leaderboard, which hosts the results, flags that the rows still come mostly from the paper's initial model suite rather than independent submissions.
OSWorld 2.0 (arXiv 2606.29537) attacks the other end: 108 long-horizon tasks across seven professional domains and 31 self-hosted sites, where the median task takes a skilled human about 1.6 hours of active operation, roughly 48 times longer than OSWorld 1.0, and leading agents average over 300 steps against about 30. At a 500-step budget, the published finding is that no system completes more than 21% end to end, with the leading system at 20.6% binary completion and 54.8% partial score. Partial scores across all evaluated systems cluster between 20% and 55%: agents make real progress and rarely finish.
Set that against OSWorld 1.0, where Simular announced in December 2025 that its Agent S framework reached 72.6%, above the benchmark's 72.36% human baseline. The same capability reads as super-human on short desktop tasks and as roughly one-in-five on hour-long workflows. Neither number is wrong. They measure different horizons, and the horizon is what your product spec actually cares about.
The buyer's takeaway from both: these benchmarks score models and harnesses, not infrastructure vendors. No leaderboard will tell you whether to run on Browserbase or Kernel. What they do tell you is that any product design assuming unattended completion of multi-step transactional work is designing against numbers that do not currently exist, which is the argument for spending your engineering budget on the handoff path rather than on the last ten points of autonomy.
Anti-bot posture: declared agent or stealth browser
This is the one decision that couples the two axes, and it is binary per session.
The declared path is Web Bot Auth, which signs HTTP requests using HTTP Message Signatures (RFC 9421) against Ed25519 keys published in a directory, per IETF drafts Cloudflare originated. Cloudflare's signed-agent category launched with a first cohort of ChatGPT agent, Goose from Block, Browserbase and Anchor Browser, and Cloudflare's own Browser Rendering already sent signed headers. Anchor exposes it as a session-level setting: enable it and every request from that session identifies as Anchor Browser. Stytch shipped support alongside Browserbase, Anchor, Cloudflare and Akamai. Anchor's own post describes the follow-on step, where origins can allow, charge or block and advertise a price via HTTP 402 for compliant bots to pay.
The standard's promotion frames this as making bot identity unspoofable. What it buys in practice is narrower: a policy lane on the origins that have chosen to honor it, and a clean answer when a partner asks who is hitting their site. On an origin that has not opted in, or that opts to block the category, declaring yourself fails closed.
The opposite posture is stealth. Rebrowser patches Chromium to remove the automation artifacts that detectors fingerprint; anti-detect browsers add fingerprint control; the proxy-first vendors bundle residential IP rotation with a browser endpoint and sell the combination. This posture wins access on sites that would otherwise refuse, and it carries the maintenance cost of an arms race plus terms-of-service exposure that your legal team, not your architect, should price.
Choose by who the agent works for. Acting inside accounts your user owns, or against partners who want the traffic: declare. Collecting from sites that have not agreed to be collected from: that is a different product decision with different risk, and it belongs in the conversation covered in agentic web access rather than in an architecture doc.
The cost model: browser-hours, concurrency, idle time
Managed browser runtimes almost all meter wall-clock browser-hours. This is the single most misunderstood line in the category, because a browser session waiting on an LLM round-trip bills identically to one that is clicking. A model-owned loop with a two-second thinking step between actions can spend the majority of its billed browser time idle. A cached Stagehand run over the same flow spends a fraction of it.
Three meters run at once:
- Browser time. Browserbase's published overage rates are $0.12 per browser-hour on Developer and $0.10 on Startup; Hyperbrowser publishes $0.10 per browser-hour. At those rates a 90-second session costs roughly a quarter of a cent, which is trivially cheap right up until concurrency and retries multiply it.
- Model tokens. Every step ships a DOM snapshot or a screenshot. On a heavy page this dominates the bill, which is the whole basis of Steel.dev's pitch about stripping content before it reaches the model. Hyperbrowser publishes AI extraction at $30 per million output tokens, which is the right order of magnitude to compare against a fraction of a cent of browser time.
- Steps and retries. Hyperbrowser publishes $0.02 per agent step for HyperAgent and Browser Use. A planner that reopens sessions or loops on an ambiguous element multiplies every other meter at once, and retry behavior, not headline price, is what decides the invoice.
The second ceiling is concurrency, and it is the one that breaks products rather than budgets. Browserbase's tiers step from 3 concurrent browsers on Free to 25, 100 and 250+; Browserless meters concurrent browsers alongside a maximum session time per plan. If your workload is bursty, the concurrency ceiling determines your p99 latency, because sessions above the cap queue. Model your peak, not your average.
Picking a combination
Four common product shapes, and the pairing each one implies.
High-volume read of JavaScript-rendered public pages. No agent framework at all. A deterministic script against the cheapest runtime that renders: self-hosted Lightpanda if the pages are text and you never need screenshots, a flat-rate Browserless plan if you want it managed. Before committing, check whether you need a browser at all; an extraction API is cheaper for URL-to-content with no interaction.
Agent acting inside a user's own accounts. Framework-mediated or model-owned loop (Stagehand for TypeScript, Browser Use for Python), on a managed runtime with live view and replay, with Web Bot Auth declared. The reliability numbers say a human will need to take over, so buy the handoff path first and treat autonomy as an optimization. Browserbase vs Steel.dev is the head-to-head if the choice is between the funded default and the open-source one.
Long-tail forms across hundreds of unfamiliar sites. Vision-first loop, because DOM selectors you have never seen are worthless. Skyvern is the direct fit, and the bundled per-step price is defensible here since you will not be tuning the runtime separately. Plan against ClawBench-shaped completion rates rather than WebVoyager ones: the tasks are the same shape as the ones where the best published score is one in three.
Continuous checks against your own product. Plain Playwright, no model in the loop, on a concurrency-priced runtime. This is a test-browser workload wearing agent clothing, and paying agent-browser prices for it is the most common overspend in the category.
The pattern underneath all four: pick the control loop from how unpredictable your targets are, pick the runtime from session length and concurrency, and let anti-bot posture follow from who the agent is acting for. Those are three separate answers, and a vendor page that collapses them into one has scoped the decision around the product it happens to sell.
Frequently asked
- What is the difference between a browser agent framework and browser infrastructure?
- Is a scraping browser just a cheaper agent browser?
- Can I run Browser Use or Stagehand on any browser infrastructure vendor?
- What does ClawBench actually measure, and does it tell me which vendor to buy?
- Should my agent declare itself or use a stealth browser?
- How much does a browser-based agent actually cost to run?
Related guides
- Search API latency for AI agents: how to build a latency budget
Jul 27, 2026 · 11 min read
- Web Access for AI Agents: Architecture & Tools
May 7, 2026 · 10 min read
- Search API, crawl API or extract API: picking the right retrieval primitive
Jul 27, 2026 · 12 min read
Compare the tools mentioned
Weekly briefing – tool launches, legal shifts, market data.