Browserbase vs Kernel
Both sell cloud browsers for AI agents. Browserbase wraps Chrome sessions of up to 6 hours in a wider platform with Search, Fetch, Functions and hosted Agents, while Kernel runs each Chromium on its own unikernel, bills memory by the second and charges nothing while a browser sits in standby.
The companies and products
Browserbase
Browserbase calls itself the complete platform to build and deploy agents that browse and interact with the web like humans: browsers, search, fetch, functions, model access and identity behind one API key.
Its core product is a headless Chrome session you drive over CDP with Playwright, Puppeteer or its open source Stagehand SDK, with proxies, CAPTCHA solving, saved browser profiles (Contexts), live view and session replays. Around it sit Search and Fetch APIs, short TypeScript Functions that run next to the browser, a Model Gateway and hosted Agents that work from a plain language goal. It is a browser platform, not a general sandbox: you get a browser, not a shell or root on the machine, so this page compares where the two overlap, which is agents that browse.
Kernel
Kernel is browser infrastructure for web agents and automations: you create cloud Chromium browsers from its API and drive them over CDP.
Each Kernel browser is Chromium on its own Unikraft-based unikernel, headless (1 GB) or headful (8 or 16 GB) with Live View and a computer controls API. Around it Kernel sells stealth mode with proxies and a CAPTCHA solver, saved browser profiles, managed logins, session replays and an app runtime for your agent code. It is a different kind of product from bochka: a managed browser, not a general sandbox, so this page compares where the two overlap, which is agents that use a browser.
Which use cases each one fits
For each use case, Battleships prices every sandbox provider on the same workload and sorts them from the cheapest monthly bill up. “24th cheapest of 367” means 23 of the other 366 providers run that workload, with every feature it needs, for less. “With limits” means the provider runs it but misses something, so it is listed after every full match. Open a use case for its whole ranking and what each provider misses.
| Use case and its workload | Browserbase: price rank | Kernel: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Neither is built for builds and tests: Browserbase gives no shell in a session, and Kernel gives a shell but no Docker or disk that stays. | 140th of 367, with limits $1,255 a month | 98th of 367, with limits $873 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An assistant that lives all month hits Browserbase's 6-hour session cap, and a Kernel browser's files go when it is deleted; bochka keeps a disk and has no session cap on paid plans. | 259th of 366, with limits $3,699 a month | 203rd of 366, with limits $2,033 a month | 5th cheapest of 366 $657 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month | 270th of 345, with limits $382 a month | 266th of 345, with limits $347 a month | 186th of 345, with limits $2,000 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month 300 sandboxes at once is above both Startup limits (100 on Browserbase, 150 on Kernel), and each user gets a browser, not a machine. | 250th of 361, with limits $1,099 a month | 228th of 361, with limits $768 a month | Cheapest of 361 $209 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month | 264th of 360, with limits $5,049 a month | 246th of 360, with limits $3,133 a month | 34th of 360, with limits $2,000 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month | 349th of 364, with limits $449 a month | 252nd of 364, with limits $390 a month | 10th cheapest of 364 $200 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month | 244th of 377, with limits $152 a month | 259th of 377, with limits $222 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB | 251st of 368, with limits $96 a month | 144th of 368, with limits $33 a month | 18th cheapest of 368 $26 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Kernel fits computer use with headful Chromium, Live View and a computer controls API, while a Browserbase session is driven through CDP and Stagehand; bochka streams a 60fps desktop for any Linux app. | 159th of 369, with limits $416 a month | 38th cheapest of 369 $1,878 a month | 6th cheapest of 369 $200 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month Both fit well and rank close (Browserbase 24th, Kernel 21st); bochka ranks 7th because the same VM that runs Chromium can also run the agent's code. | 24th cheapest of 367 $449 a month | 21st cheapest of 367 $366 a month | 7th cheapest of 367 $200 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month Both fit at startup scale, Browserbase with Fetch and Search APIs that skip the browser for simple pages, Kernel with proxies that cost nothing extra. | 55th cheapest of 346 $537 a month | 45th cheapest of 346 $443 a month | 6th cheapest of 346 $90 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month This is where both shine: Kernel ranks 4th and Browserbase 13th, with stealth, residential proxies and CAPTCHA solving that bochka does not have. | 13th of 338, with limits $9,799 a month | 4th of 338, with limits $6,000 a month | 71st of 338, with limits $1,800 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month Kernel ranks 61st against Browserbase's 229th, and bochka ranks 2nd with a full VM per run that can be forked. | 229th of 360, with limits $291 a month | 61st of 360, with limits $293 a month | 2nd cheapest of 360 $200 a month |
| GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month | Can't run it | Can't run it | Can't run it |
| macOS agents 5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month | Can't run it | Can't run it | Can't run it |
Key features
| Feature | Browserbase | Kernel | bochka |
|---|---|---|---|
| Kind of product | Managed headless Chrome sessions, plus Search, Fetch, Functions, a Model Gateway and hosted Agents | A managed Chromium browser per session, with an app runtime for your agent code | A full Linux VM per sandbox, with a desktop and Chromium inside |
| Isolation | 1 browser per VM in its own subnet; the VM is destroyed after each session | Each browser on its own Unikraft-based unikernel; cold starts under 20 ms | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Machine size | vCPU and RAM per browser not published | 1 GB headless, 8 or 16 GB headful; vCPU count not published | 4 vCPU / 8 GB by default, up to 16 vCPU / 32 GB by plan |
| Shell access | None in a browser session; hosted Agents and Functions get a shell in a short-lived runtime | SSH into the browser VM, and process exec with an as_root option | SSH and root on every machine |
| Docker and nested virtualization | Not offered | No container runtime or /dev/kvm documented | Docker, systemd and /dev/kvm on every machine |
| Session length | 6 hours on Developer and Startup, 15 minutes on Free | No documented cap while driven; deleted after an idle timeout of up to 72 hours | No cap on paid plans; you set the time to live |
| Files after a session | Only the browser profile carries over, through a Context | The browser is deleted after its timeout; profiles keep cookies, storage and browser state | The disk persists, with snapshots every minute and on stop; a stopped sandbox costs nothing |
| Idle and wake | No pause; a keepAlive session keeps billing until you release it | Standby after 5 seconds idle with a memory snapshot and no usage charge | Stop and resume by API; resume reboots from disk |
| Fork | No fork; a new session starts fresh or loads a Context | No fork; browser pools keep fresh browsers warm | Fork a running sandbox with its disk |
| Browser and computer use | Chrome with live view, session replay and logs; Stagehand act, extract and observe | Headful Chromium with Live View, a computer controls API, CDP and session replays | 60fps desktop and Chromium, computer use on any app, embeddable stream |
| Bot detection | Residential proxies in 200+ countries, CAPTCHA solving on paid plans, Verified browsers on Scale | Stealth mode with an ISP proxy and CAPTCHA solver, residential proxies, proxies not charged | Datacenter IPs and Chromium; no CAPTCHA solving |
| Reaching the machine | CDP connect URL and live view links only | No inbound ports; tokenized CDP and Live View URLs, and SSH port forwarding | HTTPS URLs for up to 50 ports, token-protected; raw TCP; own IP |
| Agents and keys | Hosted browser Agent with built-in tools; Model Gateway for OpenAI, Anthropic and Google | Claude Agent SDK app template; vaults fill logins into pages, where page scripts can read them | Claude Code, Codex, OpenCode preinstalled with a prompt, steer and events API; credentials proxy for any HTTPS API |
| Regions | Oregon, Virginia, Frankfurt and Singapore | us-east, eu-west and ap-southeast; region choice from the Start-Up plan | EU only (Germany, Finland and France) |
Every feature Battleships tracks (43)
| Feature | Browserbase | Kernel | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | No | No | Yes |
| Nested virtualization | No | No | Yes |
| Root | No | Yes | Yes |
| Systemd | No | Not published | Yes |
| Desktop GUI | No | Yes | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | No | Yes | Yes |
| SSH | No | Yes | Yes |
| Persistent disk | No | No | Yes |
| Pause/resume | No | Yes | Yes |
| Automatic snapshots | No | Yes | Yes |
| Fork/clone | No | No | Yes |
| Live fork (no pause) | No | No | Yes |
| Memory fork | No | No | No |
| Custom image (Docker or snapshot) | No | Yes | Yes |
| ≥24 h sessions | No | Yes | Yes |
| Idle auto-stop | Yes | Yes | No |
| Wake on request | No | Yes | No |
| HTTPS preview URLs | No | No | Yes |
| Raw TCP inbound | No | Not published | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | Yes | No | Yes |
| Secret proxy for any API | No | No | Yes |
| Preinstalled agents | Yes | Yes | Yes |
| Agent harness API | No | No | Yes |
| MCP server | Yes | Yes | No |
| GPU | No | Yes | No |
| Windows | No | No | No |
| Arm64 | No | Not published | No |
| Self-hosting | No | No | No |
| BYOC | No | No | No |
| Open source | No | Yes | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Not published | Yes | Yes |
| Usage per sandbox (API) | Not published | No | Yes |
| Audit logs | Not published | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Yes | Yes | Yes |
Performance
There is no comparable measurement for either. Neither Browserbase nor Kernel was in StarSling's public CPU benchmark, and neither publishes the vCPUs behind a browser, so there is nothing to set against bochka's 26.69 runs per second at 4 vCPU / 8 GB. Kernel does publish cold starts under 20 ms for its unikernels.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Browserbase and Kernel have no published run in this suite yet, so there is no like-for-like number to compare.
Pricing in five scenarios
Each bill is priced from the providers' public price lists by the open Battleships engine, with the cheapest plan that runs the scenario.
| Scenario | Browserbase, a month | Kernel, a month | bochka, a month |
|---|---|---|---|
| One coding agent, workdays 4 vCPU / 8 GB, 50 GB disk, 8 hours a day, 22 days a month, files kept between days | $99 · Startup · with limits | $5 · Free / Developer · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $122 · Startup · with limits | $34 · Free / Developer · with limits | $26 · $20/mo |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $841 · Startup · with limits | $625 · Start-Up · with limits | $317 · $20/mo × 3 seats |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $499 · Startup · with limits | $420 · Start-Up · with limits | $200 · $100/mo × 2 seats |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $1,049 · Startup · with limits | $747 · Start-Up · with limits | $2,000 · $2000/mo · with limits |
Browserbase: Browserbase plans include browser hours: 100 on Developer ($20) and 500 on Startup ($99), then $0.12 or $0.10 per browser hour, billed by the minute. Proxy data is extra after 1 GB or 5 GB.
Kernel: Kernel bills $0.0000166667 per GB-second of memory while a browser is active, so a headful 8 GB browser costs 8 times a 1 GB headless one. Standby and proxies are free, and plans of $0, $30 and $200 include $5, $10 and $50 of usage.
Kernel: You pick a monthly plan from $20, and all of it becomes usage credit spent per second on running sandboxes. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
None of the table's prices for Browserbase or Kernel is a 4 vCPU / 8 GB machine with a 50 GB disk: both are browser sessions with no published size and no disk that stays, so none of them fits. Browserbase also stops sessions at 6 hours, which rules out the workday and always-on agent. Concurrency bites next: 100 at once on Browserbase Startup and 150 on Kernel Start-Up, so 300 sandboxes for your users and 1,000 short jobs at once need Scale or Enterprise. On bochka the 1,000-job burst does not fit either, because bursts above 90 starts a minute are queued.
| Scenario | Browserbase | Kernel | bochka |
|---|---|---|---|
| One coding agent, workdays |
|
| None that bite |
| One agent that never stops |
|
| None that bite |
| 50 agents in parallel |
|
| None that bite |
| Sandboxes for your users |
|
| None that bite |
| 1,000 short jobs at once |
|
|
|
Which one should you use?
Use Browserbase when
you want one platform for web agents: Chrome sessions plus Search, Fetch, Functions and hosted Agents, Stagehand, Verified browsers for strict bot walls, and regions in the US and Singapore.
- More than a browser. Useful when simple lookups need no browser at all: Search and Fetch APIs, Functions and hosted Agents sit next to the sessions.
- Stagehand and Verified browsers. Useful if you want an open source SDK with act, extract and observe, and Verified browsers on Scale for strict bot walls.
- Regions on every paid plan. Useful if your users are in the US or Asia: sessions run in Oregon, Virginia, Frankfurt or Singapore, picked per session.
Use Kernel when
your browsers sit idle a lot or run for long stretches: free standby with memory kept, no fixed session cap, a shell in the browser VM, and stealth with proxies that cost nothing extra.
- Free standby with memory kept. Useful if agents sit idle between steps: after 5 seconds idle a Kernel browser stops charging and comes back with its pages loaded.
- A shell in the browser VM. Useful when the agent needs to run a command next to the browser: Kernel offers SSH and process exec with root.
- No fixed session cap. Useful for long browsing jobs: a Kernel browser stays alive as long as something drives it, while Browserbase stops at 6 hours.
Where bochka fits
Browserbase and Kernel both sell a browser, not a machine. If what you are really running is agents that browse and then also install, build, test or host something, bochka gives each one a full Linux VM with Chromium on a desktop, a disk that stays and coding agents built in. For stealth scraping behind bot walls, either of them is the better tool, and an agent on bochka can call them over CDP.
A whole machine with Docker
A Browserbase session gives no shell, and a Kernel browser has a shell but no documented Docker or /dev/kvm. An agent that has to run docker compose or a dev server needs a second provider, plus file copying between the two.
Files that stay and a fork
Browserbase rebuilds its VM after every session and Kernel deletes the browser after its timeout; both keep only a browser profile. bochka keeps the disk, snapshots it every minute and can fork a running sandbox to try two paths.
Hosting, agents and keys outside
Neither lets you host on a port: you get CDP and live view links. bochka gives HTTPS URLs on up to 50 ports and raw TCP, ships Claude Code and Codex you drive from outside, and keeps real API keys outside the sandbox.
Use bochka when your agent browses and also works: installs, builds, Docker and dev servers on a full VM with a disk that stays, a 60fps desktop with Chromium, hosting on 50 ports and coding agents built in. Compare it one to one: bochka vs Browserbase and bochka vs Kernel.
Questions people ask
Is Kernel cheaper than Browserbase?
In every scenario in the table, yes, though both are priced as browser sessions with no disk. One agent running all month comes to $34 on Kernel against $122 on Browserbase, and 50 agents in parallel to $625 against $841. bochka comes to $26 and $317 for a 4 vCPU / 8 GB VM that keeps its disk.
Which is faster, Browserbase or Kernel?
Neither has a comparable CPU measurement, and neither publishes the vCPUs behind a browser. Kernel publishes cold starts under 20 ms for its unikernels. bochka scores 26.69 runs per second at 4 vCPU / 8 GB in StarSling's benchmark.
Can Browserbase or Kernel run Docker?
No. A Browserbase session gives you Chrome over CDP, not a shell, and Kernel gives SSH and process exec in its browser VM but documents no container runtime. Every bochka sandbox has root, Docker, systemd and /dev/kvm.
How long can a session run on each?
Browserbase sessions last up to 6 hours on Developer and Startup and 15 minutes on Free. A Kernel browser has no documented cap while something drives it, and is deleted after an idle timeout you can set up to 72 hours. bochka has no session cap on paid plans and keeps the disk when you stop.
Which is better for scraping sites that block bots?
Both are built for it. Browserbase has residential proxies in 200+ countries, CAPTCHA solving and Verified browsers on Scale, and Kernel has stealth mode with an ISP proxy, a CAPTCHA solver and proxies at no extra charge. bochka runs Chromium on datacenter IPs and solves no CAPTCHAs.
Can I use bochka with Browserbase or Kernel?
Yes. An agent on a bochka sandbox can open a Browserbase or Kernel browser over CDP and keep its code, files and tools on the bochka VM. That puts protected browsing on them and the rest of the work on a machine that keeps its disk.
Try bochka
Install the CLI, then run bochka new.
Product preview