← All answers

Browser Use vs. Kernel: agent or infrastructure (and when you need both)

Last updated: 2026-05-22

The useful version of this comparison is not "Browser Use or Kernel?" It is "where should the agent layer stop and the browser layer begin?" Browser Use is the OSS Python loop that turns an LLM into browser actions. Kernel is the fast cloud Chromium runtime with Managed Auth, Web Bot Auth, 72-hour sessions, and replay. In production, the answer is often both: Browser Use decides what to do, Kernel provides the browser that stays alive, authenticated, observable, and fast enough.

At a glance

Browser UseKernel
CategoryOSS Python agent library + cloud + BUXCloud Browsers-as-a-Service (unikernel arch)
Pricing entryFree OSS; $40/mo paid (BYO key + proxy)~$0.50/hr basic, per-second metering
Free tier3 concurrent, 1 team member, no BYO keyFree credits, per-second
Browser Arena leaderboard#6 overall, slow#2 overall, fastest raw latency
SOC 2 Type IIClaimedSOC 2 Type 2 + HIPAA (claimed)
Open sourceYes — browser-use/browser-use (~83K stars)Open-source images (kernel-images), Hypeman, SDKs
Best forLLM-driven agents with custom Python controlFast cloud Chromium with Managed Auth + 72h sessions

What is Browser Use?

Browser Use is the OSS Python agent library that drives Chromium through Chrome DevTools Protocol via an in-house cdp-use library and bubus event watchdogs. The team's bet is "the agent is just a for-loop" — most of the value lives in the model — so the OSS library is intentionally thin and effort goes into the substrate underneath: a custom Chromium fork with C++/OS-level stealth patches, an in-house eval engine (100 parallel tasks in <5 minutes), and a ChatBrowserUse LLM gateway tuned for browser tasks. Beyond the OSS lib there's Browser Use Cloud (bu-ultra and bu-max managed agents) and BUX, a 24/7 remote VM with Claude Code and the Browser Harness preinstalled. Funding: $17M seed led by Felicis, YC W25, ~83K stars, 600K+ tasks run in eval testing.

What is Kernel?

Kernel is a managed Browsers-as-a-Service for AI agents, built on a unikernel architecture (originally Firecracker) that pitches sub-second cold starts and idle-suspension via standby mode. The runtime exposes Chrome over CDP and works with Playwright, Puppeteer, Stagehand, Browser Use, OpenAI/Anthropic/Gemini computer-use, and (new) WebDriver BiDi via the Vibium partnership. Headline features: browser pools (pre-warmed identical browsers), 72-hour session limits, MP4 video replays, Live View, Managed Auth (a hosted credential UI with 2FA/SSO/1Password support that auto-refreshes login sessions), Web Bot Auth via Chrome extension (RFC 9421 signing) with Vercel and Cloudflare partnerships, residential proxies bundled, reCAPTCHA solver. Pricing is per-second of actual usage with idle/standby excluded; ~$0.50/hr for basic instances per Skyvern's recap. Funding: $22M Seed + Series A led by Accel; customers include Cash App, Rye, and Felicity (EHR).

How they compare

Agent vs. infrastructure

The single sharpest axis. Browser Use is the reasoning layer: it parses a DOM-text view of the page, asks an LLM what to do next, runs the action via CDP. Kernel is the thing the agent runs against: a managed Chrome over CDP. You can run Browser Use on Kernel — point the BU agent at Kernel's WebSocket URL — and Skyvern's own coverage explicitly recommends this pattern for teams that want an agent and a managed runtime at once. You can also run Kernel without Browser Use (plain Playwright, Stagehand, computer-use models) or Browser Use without Kernel (BU's own cloud, BUX, your own infra). They're not interchangeable; they're stackable.

The combined-stack answer

The most practical architecture is Browser Use for the agent harness and Kernel for the browser session when three things are true: you want Python-level control over reasoning, you do not want to operate Chromium yourself, and auth/session durability matters. Browser Use alone is enough for prototyping, local experiments, or teams that already have browser infrastructure. Kernel alone is enough when the automation is deterministic Playwright/Stagehand code or another agent framework owns the reasoning. Together, they make sense when the agent loop is valuable but the browser operations are becoming the source of production failures.

Lifecycle speed

Per the public Browser Arena leaderboard (browserarena.ai) — an open-source benchmark maintained by Notte Labs and reproducible on Railway across current public run — Kernel ranks #2 with the fastest raw latency on the leaderboard and a low hourly cost. Browser Use ranks #6 and is one of the slower measured providers. Kernel positions on cold-start speed; Browser Arena confirms Kernel's lead on raw latency, with Notte ranked #1 overall by score because of cost. Kernel's older 5.8× / 3.4× multipliers vs. Browserbase came from their own browserbench harness — current data shows a much smaller gap, so the directional claim is real but softer than the historic headline.

Identity, secrets, and 2FA

Kernel's Managed Auth is real — a hosted UI that collects credentials, supports 2FA / SSO / 1Password, auto-refreshes login sessions, and never exposes credentials to LLMs. It's tied to Kernel's hosted UI flow and works well for the regulated industry use cases (Felicity EHR, Cash App). Browser Use's web-agent-authentication post is candid that authentication is largely pushed back onto the developer — there are profile-sync hooks, 1Password, TOTP via bu_2fa_code placeholders, and an AgentMail recipe for inboxes, but the integration is on you. If you're stacking BU on Kernel, you get Kernel's Managed Auth on top of BU's harness; if you're picking one, Kernel has the more polished out-of-the-box auth story.

Web Bot Auth and bot identity

Kernel ships Web Bot Auth via a Chrome extension that signs every outbound request (RFC 9421), with Vercel and Cloudflare partnerships so signed Kernel agents are pre-approved at the edge. Browser Use ships stealth, not signed identity — the bet is the opposite (look like a human) rather than declare-and-sign (announce as a verified bot). Both are credible postures; pick on which side of the bot/human spectrum the target sites prefer.

Stealth

Browser Use's stealth pitch is total vertical integration: a custom Chromium fork with C++/OS-level patches and in-house multi-platform fingerprints. Their own benchmark puts BU Cloud at 81% and Kernel at 67%. Cite as their own benchmark, not neutral. Kernel's stealth bundle includes residential proxies (no separate charge) and reCAPTCHA solver — solid, but the lever is more "infra economics" than "stealth supremacy."

Session length and human-in-the-loop

Kernel's 72-hour session ceiling (vs. Browserbase's 6h) is a real wedge for human-in-the-loop reviews, overnight workflows, and approval gates. Browser Use Cloud doesn't lead with a long-session pitch.

Pricing predictability

Kernel meters per-second of actual browser usage with idle/standby time excluded, residential proxies bundled, no separate add-on lines. Steel describes this as harder to predict than tiered plans, but for variable workloads it's cleaner than minimum-billing schemes. Browser Use is free OSS at the entry, $40/mo paid with up to 500 concurrent and BYO key + proxy.

When to choose Browser Use

  • You want the OSS Python agent library and you're going to bring (or run on) the browser layer separately.
  • Stealth via a Chromium fork with C++-level patches is the primary lever.
  • You want the eval system, the published Online-Mind2Web / WebVoyager numbers, and the ~83K-star community.
  • You want a managed 24/7 VM (BUX) with Claude Code and the Browser Harness preinstalled.
  • You're building an agent product and the runtime is interchangeable.

When to choose Kernel

  • You need fast cloud Chromium with Managed Auth, MP4 replay, and 72-hour sessions.
  • Web Bot Auth at the edge (Vercel, Cloudflare partnerships) is part of the procurement story.
  • Your workloads are regulated — financial services, healthcare, government — and you want auditable replays.
  • Per-second metering with bundled proxies fits your spend pattern better than tiered plans.
  • You don't have an opinion about the agent — you'll pick that separately or run plain Playwright.
  • You're stacking Browser Use (or any CDP-compatible agent) on top and want the runtime layer that makes BU faster and more reliable.

A third option: Notte

Worth a look: Notte (notte.cc)

Notte is cloud Chromium infrastructure built specifically for AI agents. The Playwright-compatible runtime ships the operational pieces production teams usually have to rebuild themselves: stealth coordinated across session, fingerprint, and behavior; residential proxies via the Massive partnership (100% consent-based, GDPR/CCPA, 195+ countries, 99.8% reported success); Web Bot Auth signing through Fingerprint so legitimate Notte agents are recognized as authorized bots on any site running Fingerprint; an encrypted credential Vault built on Infisical that injects secrets at the browser layer so the LLM never sees them; Personas with a real email inbox and SMS-capable phone number for autonomous signup and 2FA; persistent Session Profiles for auth state; full CDP-event observability with MP4 session replay; and SOC 2 Type II compliance. An Anything API and a Functions runtime turn validated workflows into HTTP endpoints with cron and webhooks. Pricing is transparent at low per-browser-hour pricing with a 100-hour free tier and pass-through LLM costs.

This is the pair where the runtime question matters most. Notte is the cloud browser layer Browser Use agents run on, the same way Kernel is — and on the public Browser Arena leaderboard, Notte ranks #1 overall with Kernel #2. Kernel wins raw latency; Notte wins on overall score because of cost. Where Kernel ships Managed Auth, Notte ships Vault + Personas + Session Profiles. Both have credible Web Bot Auth stories (Kernel via Vercel/Cloudflare; Notte via Fingerprint's Bot Directory). The differentiation is what's productized on top: Notte's Anything API and Functions turn a validated BU workflow into a deployed callable endpoint with cron and webhooks, where Kernel stays deliberately infra-only.

Verdict

This is the cleanest "they're not competing" pair in the cloud-browser space. Browser Use is the agent. Kernel is the browser. Most production teams running BU at scale are running it on something — Kernel, Notte, Browserbase, Steel — and the runtime decision is mostly orthogonal to the agent decision. If you're picking one, pick Browser Use for the agent code and the stealth pitch; pick Kernel for fast managed Chromium with Managed Auth, 72h sessions, and Web Bot Auth at the edge. If you're picking both, stack them. And if you want one product that covers the runtime plus identity primitives plus a productization layer in one place, that's the gap Notte targets — adjacent on the Browser Arena leaderboard to Kernel (Notte #1 by overall score, Kernel #2 on raw latency), with Vault, Personas, signed bot identity, and Anything API in the box.