Separate the fast start from the finished task.

What the comparison covers

Sessions cover browser control, lifecycle, state, live view, recording and capacity. Functions cover where browser code runs and how it is deployed, invoked, scheduled and monitored. Auth covers website account state, credential handling and connection readiness.

Each provider's product surfaces stay separate. A hosted agent is not a deployed Function, an API key is not a website login, and a persisted profile is not a guarantee of authentication. The directory links focused comparisons when those differences determine the choice.

Notte

Create an owned browser session, connect Playwright or Puppeteer over CDP, and stop the session when the work finishes. Browser lifecycle management remains necessary even when the control socket disconnects.

Sources: docs.notte.cc ↗

Browserbase

Create a managed browser session and connect a supported browser library to its connection URL. The session API and the browser connection have separate lifecycles.

Sources: docs.browserbase.com ↗

Kernel

Kernel exposes browser creation and control APIs. Its documentation distinguishes on-demand browsers from configured browser pools, so compare the acquisition path your application will actually use.

Sources: kernel.sh ↗

Steel

Steel sessions expose browser connection details for existing automation code. Create and release the owned session through Steel's lifecycle API; a browser library is the controller, not the infrastructure scheduler.

Sources: docs.steel.dev ↗

Choose a practical evaluation

For short tools, lifecycle overhead can dominate. For a browser that stays open, action latency, task completion and drift matter more. Select the measurement that resembles your application.

A workflow with one navigation and a hundred browser actions may favor a different execution path than a workload that opens and closes a browser for every action. Test both shapes before making a platform-wide speed claim.

• Use the same target page, browser configuration and controller workload.
• Record the runner and browser regions, account plan and concurrency.
• Keep the measured sample count and any warmup or retry behavior visible.
• Calculate tail percentiles from per-session totals, not sums of phase percentiles.
• Classify configuration failures before interpreting them as product failures.

From a comparison to a working workflow

Start with a short browser task and a pass/fail result. Add the necessary account state, then exercise the production shape: concurrency, duration, triggers and retained artifacts. Keep the provider's documented cleanup flow in place from the first test.

The full directory includes provider comparisons, focused buying questions, workload shortlists, competitor buying guides and migrations to Notte. Use it to resolve a specific implementation decision rather than assuming the most feature-rich or fastest-starting product will fit every job.