Browserbase vs Kernel for browser agents.

Both vendors create managed Chromium sessions. Both expose standard browser connections. Their execution choices differ above that layer.

Browserbase supports external library connections. Its plans also include hosted agent runs and Functions. Kernel's default surface runs Playwright inside the browser VM.

Kernel also exposes OS-level controls. Kernel adds WebMCP and a browser REPL. Browserbase documents browser-oriented MCP tools. Each path changes latency and ownership.

Start with current application boundaries. Keep orchestration placement explicit. Avoid choosing from benchmark headlines alone.

Browserbase sells plans with included browser hours. Developer costs $20 a month for 100 hours. Startup costs $99 for 500 hours. Overage runs $0.12 or $0.10 per hour.

Kernel charges a monthly fee plus per-second usage. Hobbyist costs $30 a month. Start-Up costs $200 a month. Included credits apply to usage only. Headful seconds cost eight times headless seconds.

Idle time separates the two billing models. Kernel enters standby after five idle seconds. Standby stops usage charges but keeps the concurrency slot. Browserbase keep-alive sessions bill until release or timeout.

Session ceilings differ in kind. Browserbase Developer and Startup sessions run up to 6 hours. Its plans doc lists Scale at 6-plus hours. Browserbase Free sessions stop at 15 minutes. Kernel's timeout governs idle deletion, up to 72 hours. Kernel's cited pages state no active-session ceiling.

A browser endpoint is one choice. Code placement is another choice. Agent reasoning placement adds a third.

Browserbase returns connection details for libraries. Its MCP server provides browser-oriented tools. Hosted Functions add vendor-side execution.

Kernel lists six control surfaces. Playwright execution is its default. Computer controls drive mouse, keyboard, and screenshots. The rest are WebMCP, REPL, CDP, and WebDriver BiDi.

Browser control modes are not interchangeable. Each exposes different debugging evidence. Each creates different portability costs.

Session names hide different state machines. Browserbase separates connection, keep-alive, context, and closure. Kernel adds active and standby behavior.

Kernel standby preserves browser state temporarily. Billing stops during documented standby. Its timeout begins after standby starts.

Browserbase keep-alive supports reconnection after disconnection. Keep alive requires a paid plan. The session still follows configured duration limits. Contexts address later-session browser data.

Write each transition into application logs. Include vendor identifiers and timestamps. Treat missing transitions as failed evidence.

Both vendors support reusable browser state. Browserbase calls its primitive a context. Kernel calls its primitive a profile.

Browserbase contexts preserve several Chromium data stores. Persistence must be requested on sessions. Synchronization follows session closure.

Kernel profiles need save_changes for writes. Deletion or timeout then saves state. A normal Playwright close does not save. Kernel can also save a running browser. Saving replaces the whole profile.

Profile write rules change application design. Assign one writer per identity. Add locks around mutable profile use.

Vendor benchmarks cannot settle your workload. Runner geography influences every network measurement. Browser mode changes resource requirements.

Use one pinned task and browser configuration. Run both vendors from one runner. Alternate vendors to reduce time drift.

Record raw timestamps, not summary claims. Keep failures inside the sample. Publish exclusions before running anything.

The idle phase matters separately. Kernel documents standby billing behavior. Browserbase documents browser-time allocations and rates.

Browserbase provides a session inspector. Its documented surface includes logs, network data, metrics, and replay. Live View supports human control.

Kernel provides Live View and optional replays. Kernel lists Live View and replays as headful features. It also documents structured telemetry. App deployments can provide invocation logs.

More artifacts do not guarantee faster diagnosis. Identifier linkage matters more. Retention and export needs also matter.

Create two deliberate failures. Break one selector and one connection. Measure the path to root cause.

Kernel publishes browser pools for repeated workloads. Pools reserve ready browsers with predefined configuration. Reserved capacity counts against concurrency.

Browserbase publishes plan concurrency. Keep-alive can reduce repeated session creation. Those mechanisms solve related pressure differently.

A faster individual start may not improve queues. A pool may reduce configuration startup work. It also consumes reserved capacity.

Measure queue delay separately. Measure browser readiness separately. Price active runtime and capacity constraints separately.

Pool reuse needs an isolation decision. Released pool browsers keep cookies and tabs by default. Release with reuse false for per-user work. Pool profiles load read-only.

Both vendors document browser configuration controls. Browserbase lists proxies and plan-dependent stealth settings. Kernel documents stealth and proxy settings for browser pools.

Configuration controls do not establish access reliability. Run identical tasks on sites that permit your work. Match browser configuration, geography, request pace, and login state.

Record completed pages, challenges, retries, and queue delay. Check session continuity and failure evidence. Compare cost per completed task, not vendor labels.

Direct CDP migration offers the narrowest trial. Keep current Playwright logic unchanged. Replace only creation and connection code.

Do not add co-located execution immediately. That would combine vendor and architecture changes. Baseline behavior would become ambiguous.

Next migrate persistent state. Use one profile writer. Confirm explicit deletion triggers the expected save.

Finally consider Kernel-specific control paths. Compare those paths against measured needs. Preserve a rollback adapter until acceptance.

Legba publishes an agent skill, HTTP sessions, and hosted MCP. It provides routing and isolated browser sessions.

Legba's hosted browser supports a documented human handoff. A person takes control through a view link. The agent resumes afterward through session controls.

Remote CDP and Playwright attachment remain undocumented. These sources establish no platform equivalence. Some teams need infrastructure control planes. Others need a callable isolated route.

Choose from the actual job. Avoid buying unused platform breadth. Validate the required agent path.