Browserbase vs Browser Use vs Kernel: what will your agent cost?

For a small team building a browser agent, the useful comparison is the cost and reliability of a completed workflow. A browser-hour rate tells you little about model calls, proxy traffic, failed logins, or the engineer who has to rescue a stuck run. Start with one real task, such as downloading an invoice from an account you control.

Browserbase, Browser Use, and Kernel offer hosted browser infrastructure, but their billing units and bundles differ. Browser Use also sells a managed agent layer. Decide whether you need a remote browser for your own automation code or a service that runs the agent loop before comparing prices.

What the current price sheets actually say

Sources: Browserbase plans, Browser Use pricing, Kernel plans, and Kernel usage rates. Kernel’s hourly figures above are calculated from its documented per-second rates, before credits. Headful and headless are different configurations, not interchangeable prices for an identical run.

Calculate a workload, not just a unit price

Suppose your workflow makes 1,000 attempts a month, each occupying a browser for three minutes. That is 50 browser hours. If 800 attempts succeed, you must divide the total bill by 800, including the cost of the 200 failures.

At the published rates, that browser-only illustration fits inside Browserbase Developer’s $20 monthly allowance; Browser Use browser time is $1. Kernel would be about $3 headless or $24 headful if all 50 hours were active, before credits and plan fees. This arithmetic is not a full-service ranking: it excludes model calls, traffic, application compute, support, and human recovery. Browser Use rounds browser billing up to whole minutes, and Kernel excludes idle time.

A single gigabyte of extra residential proxy traffic can outweigh a low browser-time bill. A slow model can also keep a session occupied. Collect usage by component during the trial; do not estimate all costs from the duration of a successful demo.

Choose a first candidate by the work you already own

• Browserbase: a candidate when you want a bundled allowance and a defined concurrency tier. Test whether the chosen plan covers your peak, not only your monthly average.
• Browser Use: a candidate when you want to compare running your own browser logic with buying a managed agent loop. Keep those two trials separate so you know what changed.
• Kernel: a candidate when active runtime, browser configuration, and idle behavior matter to your workload. Measure the configuration you will deploy.

These are starting hypotheses. We have not run an independent reliability benchmark of the three services. Vendor benchmark scores and customer quotes cannot establish success on your authenticated workflow.

Authentication is part of the architecture

For invoice retrieval, a fresh browser is useful only until it meets the login screen. Browserbase Contexts preserve cookies and application data across sessions. Saving new state requires persist: true; its documentation says to wait briefly after closing before reusing the context. It also advises against simultaneous logins with the same context. A concurrency allowance does not mean one customer’s login can safely serve that many concurrent jobs.

Browser Use’s Cloud quickstart offers two distinct paths: send a task to a hosted agent, or connect your own Playwright or Puppeteer code to a cloud browser over CDP, the Chrome DevTools Protocol. Its open-source library is another deployment choice. A useful trial keeps the driver fixed while changing browser infrastructure, then separately tests whether a managed agent can replace your driver.

Kernel documents headless and headful browsers, CDP and WebDriver BiDi connections, persistent profiles, and Managed Auth. These are reasons to investigate it when login state and browser control are substantial parts of your application. Confirm the current SDK and profile lifecycle: its API reference marks the older persistence field as deprecated in favor of profiles and session timeouts.

In all three trials, assign state to the correct customer and account. Test a second session after a successful login, then revoke that login at the destination site and repeat. The pass condition is a recognized need to authenticate again. Silently reusing another account’s session is a failure, even if the requested file downloads successfully.

What a realistic invoice trial should return

Use ten invoices whose account, billing month, currency, and amount you already know. Include one missing invoice and one delayed download. Require the agent to return the file and those four fields, plus a result such as “downloaded,” “not available,” or “needs login.” A screenshot of a download button is insufficient. Open the returned file and compare its contents with the expected invoice.

Log the job ID, browser session ID, attempt number, model, browser mode, billed runtime, traffic, and human recovery time. Store customer content separately from this operational record. That separation lets an engineer compare costs without copying every invoice into a debugging log.

Illustrative monthly workload, not benchmark results:
1,000 attempts × 3 minutes = 50 browser hours
800 verified results = 80% acceptance
100 recoveries × 2 human minutes = 200 minutes
At an assumed $60/hour, recovery alone costs $200

All-in cost per result =
  (plan + browser + traffic + model + compute + recovery) / 800

The recovery assumption can dominate differences of a few dollars in browser runtime. Measure it before negotiating infrastructure rates. Also run a burst test: fifty jobs arriving together have different queue requirements from fifty jobs spread through a day. Set a deadline for the last completed job, not only an average duration for successful runs.

Run the same failure cases on each service

Use test accounts and retain enough evidence to diagnose failures. Check access and retention for recordings: a replay can contain customer information. For setup and permission boundaries, use our browser workflow guide. Buy after you can explain both a successful run and a failed one.

Agentlist editorial review. Sources checked October 12, 2026. This is a documentation-based buying guide, not a hands-on performance benchmark. Trial procedures and recommendations are our analysis.