What must a successful browser workflow do?
Write down the required page actions, account state, execution duration and completed work before looking at a ranking. A fast browser that lacks a required action or state contract is not a substitute for a working workflow.
A session creation number measures one API operation. A usable browser also needs a connection and a navigation, and a long-running workflow pays for many actions after startup. Compare lifecycle latency and running-task throughput separately.
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 ↗
Anchor Browser
Anchor sessions can be controlled over CDP or REST. Its documentation separates direct browser control from natural-language tasks and versioned automation tasks.
Sources: docs.anchorbrowser.io ↗
Evaluate the operational difference
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.
Make the acceptance test explicit
Describe the work that must finish, the account it runs under, the state it needs to retain and the expected output. Select eligible product configurations before measuring latency or price.
Run the same workflow with each proposed architecture. Keep startup measurements separate from task execution, and distinguish provider failure from a configuration error or an unsupported website action.
Choose the responsibility you want to own
An external runner keeps deployment and queues in your application. A hosted execution layer moves part of that responsibility to the browser platform. Saved browser state reduces repeated setup, while managed website authentication may add readiness checks. Choose each part deliberately rather than treating a brand as one indivisible feature list.