The evidence should be easy to inspect.

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.

Published browser measurements

These are the latest provider runs in the saved BrowserArena snapshot checked on October 18, 2026. Dates and runner environments can differ. A lifecycle test opens, connects, navigates and releases a browser; the throughput test runs a separate browser action sequence. Neither measures managed authentication or deployed Function reliability.

Use these observations to choose what to test in your application. An account-configuration failure, an incompatible page action and a timed-out navigation require different interpretations. BrowserArena is maintained by Notte and publishes its source and methodology.

Sources: browserarena.ai [1] ↗browserarena.ai [2] ↗github.com [3] ↗

Evidence and updates

The saved benchmark snapshot retains provider run dates, runner locations, instance types and measured sample counts. Latest-per-provider rows can come from different runs and environments, so they are indicative observations rather than a controlled same-machine race.

Product facts link to public documentation checked on the displayed date. An unknown means the reviewed sources did not establish support. A conditional, preview, beta or composed capability remains labeled instead of being reduced to a green check.

Notte writes these comparisons and maintains BrowserArena. The library includes cases where another provider's execution or deployment model fits better. Use the linked source and your own authorized workflow to challenge a recommendation.

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.