Skip to content
Guideintermediate

Kitesurf vs Browserbase vs Browser-Use: which agentic browser for your AI agent stack (Aug 2026)

The short version

Cloudflare Kitesurf, Browserbase, and Browser-Use solve three different problems for agent builders. Here is which one to pick based on your task type, budget, and infrastructure.

Published August 19, 2026by Pondero Reviews
Table of Contents

Kitesurf vs Browserbase vs Browser-Use: which agentic browser for your AI agent stack (Aug 2026)

A full Chromium instance costs more than most agent tasks are worth. Chrome was built to render a page for a human who might click anything on it; an agent that just needs one screenshot and a chunk of clean HTML still pays for tabs, extensions, and a rendering pipeline it never touches. Three tools now attack that waste from different angles. Cloudflare's Kitesurf, which launched August 6, 2026, strips the browser down to what an agent actually uses and runs it inside V8 isolates on Workers (per Cloudflare). Browserbase keeps the full Chromium engine but manages it for you, with session recording and stealth mode built in. Browser-Use skips the managed layer entirely and hands the LLM direct control of a Playwright-driven browser you host yourself.

The short version: a one-shot screenshot or extraction job on Cloudflare Workers starts with Kitesurf, free in beta. A workflow that spans several steps and has to survive a login wall or a bot check is worth paying Browserbase for. Full control over the stack, or a rule that page content can't leave your own infrastructure, points at Browser-Use. The rest of this piece defends each pick and shows where it flips.

When your agent needs a browser at all

Not every task needs a browser. A browser is the expensive tool: it parses HTML, runs JavaScript, holds cookies and DOM state, and burns CPU doing it. If a page is static or lightly scripted, a scraping API like Firecrawl, Tavily, or Exa returns clean markdown in one HTTP call and skips all of that overhead, a distinction we cover in our comparison of the three search APIs. The rule that actually holds up: reach for a browser when the page requires JavaScript execution to render its content, or when the task depends on session state, a login, a cart, a multi-step form. Reach for an API when the content is already sitting in the HTML or a search API can pull it in one pass.

Some sites blur that line by shipping a cooperative machine interface alongside the human UI, which changes the calculus again. We cover that middle ground, and when a protocol like WebMCP replaces a full browser session, in our WebMCP vs Playwright vs Firecrawl guide. Once you've decided the task genuinely needs a browser, the question becomes which one.

Kitesurf: an agent-shaped browser that runs inside a Worker

Kitesurf isn't Chromium with features removed. It's a new rendering stack, built fast: the team's first commit landed in May 2026, twelve weeks before the August 6 launch (per Cloudflare's launch post). HTML and CSS parsing come from Blitz and Firefox's Stylo CSS engine, both written in Rust and compiled to WebAssembly, and page JavaScript runs inside the Worker's own V8 isolate rather than a bundled browser engine. The one exception is eval(), which Workers don't support natively, so Kitesurf falls back to Boa, a Rust-based ECMAScript engine, only for that case (per the same post). Cloudflare cut everything a human browsing session needs and an agent doesn't: tabs, themes, extensions, device sync, pixel-perfect rendering. What survives is the Chrome DevTools Protocol, so Puppeteer, Playwright, and any MCP client that already speaks CDP work against Kitesurf without a rewrite.

The cost claim is specific, not a marketing round number. Cloudflare's own benchmark, medians of five runs across a 14-URL corpus, puts Kitesurf at 380ms of CPU for a screenshot against Chromium's 1,173ms (3.1x less), and 229ms against 877ms for HTML extraction (3.8x less). Memory tells the bigger story: 57.8 MiB versus 271.0 MiB for a screenshot (4.7x less) and 39.4 MiB versus 273.7 MiB for HTML extraction (7.0x less) (per Cloudflare). Wall time is the one number that runs the other way: Chromium's warm JIT still finishes faster, by roughly 1.7 to 1.8x, because a cold Rust renderer can't beat an engine that already compiled the page once. If your bill tracks CPU and memory rather than the stopwatch, that trade favors Kitesurf.

Kitesurf is free while in beta, and turning it on is an existing-client change, not a migration. Add browser=kitesurf to any Browser Run CDP or Quick Action endpoint and your current Puppeteer or Playwright code runs against it (per Cloudflare's changelog):

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <API_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{"url": "https://example.com"}' \
  --output "screenshot.png"

Input: any URL. Command: a Quick Action POST with browser=kitesurf set. Expected output: a PNG written to screenshot.png, the same shape Chromium's default endpoint returns, just cheaper to produce (per Cloudflare's Kitesurf docs).

The candid con: Kitesurf is stateless by design, built to exist for the duration of one task and then disappear. Cloudflare's own docs say it plainly. It isn't yet the option for playing video, rendering WebGL, negotiating a bot-challenge handshake that checks real TLS fingerprints, or holding a long authenticated session (per the same docs). It also doesn't render every site correctly yet. TodoMVC, Wikipedia, Hacker News, and the Cloudflare Blog work; a complex JavaScript-heavy single-page app may not. Cloudflare publishes a public playground where you paste a URL and watch Kitesurf render it with DevTools attached, the fastest way to learn whether your target site is compatible before you wire anything up.

Browserbase: managed Chromium for multi-step, stealth-sensitive work

Browserbase runs full, unmodified Chromium in the cloud and hands you a Playwright or Puppeteer connection to it, so your existing browser-automation code barely changes beyond the connection string. Every session records to a replay you can scrub through later, with a live debugger for watching a run as it happens, which matters when an agent goes wrong at step 40 of a 60-step task and you need to see exactly where. Stealth mode and rotating proxies handle sites that actively try to block automated traffic, and sessions persist well past the minutes Kitesurf is built for, useful for a checkout flow, an authenticated scrape, or anything that has to survive a login and stay logged in across several actions.

Connecting Playwright is a small code change, not a new SDK to learn:

import { chromium } from "playwright-core";
import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY });
const session = await bb.sessions.create();
const browser = await chromium.connectOverCDP(session.connectUrl);
const page = browser.contexts()[0].pages()[0];
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });

Input: an existing Playwright script. Command: swap chromium.launch() for chromium.connectOverCDP(session.connectUrl). Expected output: the same page object, now driving a browser Browserbase hosts instead of one on your own machine (per Browserbase's Playwright quickstart).

Pricing, pulled from the live page in August 2026: Free gives 3 concurrent browsers and 1 browser hour a month at no cost. Developer, at $20 a month, includes 100 browser hours (then $0.12 an hour) and basic stealth mode. Startup, at $99 a month, is Browserbase's own most-popular tier and includes 500 browser hours (then $0.10 an hour), 5 GB of proxy traffic, and 30-day data retention. Scale is custom, usage-based, with advanced stealth and SSO for enterprise buyers (per Browserbase's pricing page, accessed August 19, 2026). Browserbase's own guidance puts a typical scrape under two minutes, so 100 hours covers roughly 3,000 page-level tasks, worth knowing before you pick a tier. The candid con is the same one every managed service carries: you're paying by the hour for something you could run yourself, and that math only favors Browserbase once the stealth and session-state work is worth more than the bill.

Browser-Use: self-hosted, LLM-driven, no vendor in the loop

Browser-Use is an open-source, MIT-licensed Python library, at 109.7k GitHub stars as of August 2026, that wraps Playwright and lets an LLM drive the browser directly through tool calls instead of you scripting every click (per the browser-use/browser-use repo). You describe the task in plain language, hand the agent an LLM (the project supports OpenAI, Anthropic, and its own hosted models), and it plans and executes the browser actions itself.

import asyncio
from browser_use import Agent, ChatBrowserUse

async def main():
    agent = Agent(
        task="Find the number of stars of the browser-use repo",
        llm=ChatBrowserUse(model="bu-2-0-mini-preview"),
    )
    await agent.run()

asyncio.run(main())

Install and setup, copy-paste runnable:

uv add browser-use
# or: pip install browser-use
echo "BROWSER_USE_API_KEY=<YOUR_KEY>" >> .env

Input: a plain-language task string. Command: agent.run(). Expected output: a browsing session that navigates, reads the page, and returns the requested answer, driven by the LLM's own tool calls rather than a fixed script (per the repo's quickstart).

The tradeoff is the one every self-hosted tool makes. You run it on your own server or VM, so there's no per-hour bill, no vendor seeing your page content, and full access to whatever Playwright can do. You also own the compute, the browser dependencies, and the scaling work that comes with them. Browser-Use's own benchmark claims the top spot on the Odysseys leaderboard for long-horizon web tasks, and the project itself recommends pairing the open-source agent with a managed cloud browser, its own or a competitor's, for stealth and proxy rotation at scale (per the repo README). That's a tell worth reading closely: self-hosting solves the vendor-dependence problem, not the anti-bot problem Browserbase was built for.

The comparison table

DimensionKitesurfBrowserbaseBrowser-UseSource
Cost modelFree in betaFree tier, then $20 to $99+/mo, usage past included hoursYour own compute, no per-hour feeCloudflare / Browserbase
Session typeStateless, one-shotPersistent, minutes to hoursPersistent, bound by your own infraCloudflare docs
JS rendering fidelityGood on compatible sites, not pixel-perfectFull Chromium, pixel-perfectFull Chromium via PlaywrightCloudflare docs
Stealth / anti-botNone yet, no TLS fingerprint negotiationBuilt in, basic to advanced by tierNone natively, pair with a managed browserCloudflare docs / Browserbase
Infrastructure neededNone, runs on WorkersNone, fully managedYour own server or VMbrowser-use repo
Best task typesScreenshots and HTML extraction at scaleMulti-step flows, authenticated scraping, stealth-sensitive sitesFull control, cost-predictable scale, data that can't leave your infraCloudflare docs

Which one to pick

  • One-shot screenshots or HTML extraction at scale, already building on Cloudflare Workers: Kitesurf edges out the alternatives. It's free in beta, the API is a parameter change rather than a migration, and the CPU and memory savings compound fast at volume.
  • Multi-step workflows that need session state or have to get past bot detection: Browserbase. The persistent sessions, stealth mode, and replay debugger are worth paying for on anything that spans a login or a checkout.
  • Full control, self-hosted, page content that can't leave your own infrastructure, or high enough volume that a per-hour bill adds up fast: Browser-Use. You carry the ops burden, but nothing leaves your servers and there's no usage meter watching you.
  • A complex, JavaScript-heavy single-page app Kitesurf doesn't render fully: skip Kitesurf here and use Browserbase or Browser-Use, both running full Chromium under the hood, until Kitesurf's compatibility catches up.

What changes now that Kitesurf exists

Before August 2026, the honest answer to "how do I give my agent a browser" was Browserbase or Browser-Use, full stop, because a hyperscaler-native option built around agent workloads didn't exist yet. Kitesurf splits that decision instead of replacing anyone. It doesn't compete with Browserbase on session depth or stealth. It competes on the much larger volume of tasks that are genuinely one-shot: a screenshot, a page of extracted text, a PDF, the kind of job a full Chromium instance was always overkill for. That's most of what a scraping-heavy agent pipeline actually runs, hour to hour. Cloudflare's docs already report Kitesurf passing more than 235,000 WPT subtests and adding hundreds more every week (per Cloudflare's Kitesurf docs), so the set of sites it renders correctly keeps growing.

That leaves Browserbase's paid tiers earning their cost exactly where they always should have: sessions that need to persist, sites that fight back against automation, and JavaScript Kitesurf can't yet render. Browser-Use still owns the case both of the other two opt out of, running your own stack with nobody else touching your data. None of the three replaced the others. Kitesurf just pulled the majority of the cheap, one-shot workload off Browserbase's plate, and that was the workload that never needed a full browser in the first place.