How many browsers can be open, and how quickly can they start?
A concurrency entitlement does not promise that every browser can start in one burst. The creation-rate limit and the application queue determine how quickly new work becomes runnable.
Concurrent sessions, session creation rate and HTTP request rate are different limits. A plan that allows a hundred open browsers may still need time to start them. Polling or retrying without a budget can exhaust API capacity before the browser cap is reached.
Notte
The public plans list 5, 25 and 100 concurrent browser sessions, with custom limits on Enterprise. Session duration and concurrent capacity are separate plan limits; a larger technical API limit does not override the plan.
Sources: notte.cc ↗
Browserbase
Browser and Function constraints have separate documentation. Check the account's concurrent browser limit, the Function runtime cap and the Function region rather than assuming a browser entitlement covers every execution path.
Sources: docs.browserbase.com ↗
Kernel
Kernel documents concurrent browsers, browser creation rate and per-browser resources separately. Standby browsers can still consume concurrency. Pools change how browsers are acquired; they do not erase account limits.
Sources: kernel.sh ↗
Anchor Browser
Anchor documents a batch-session API as well as asynchronous session creation. A large batch request is distinct from how quickly every browser becomes ready, so measure the ready state and plan-specific conditions.
Sources: docs.anchorbrowser.io ↗
Evaluate the operational difference
A quota table establishes what an account may request. A measured concurrency curve establishes how the tested workload behaved. Keep both in the decision and avoid extrapolating a single-session result to a large fleet.
If a thousand jobs arrive together but only fifty browser slots are available, queue jobs before allocating browsers. Starting all jobs immediately can turn ordinary capacity management into timeouts, retries and idle browser charges.
- Specify the number of simultaneously open browsers and the burst arrival rate.
- Measure time until every requested browser is ready for work.
- Record rate limits and honor the returned retry delay.
- Cap worker concurrency and keep queued tasks outside browser sessions.
- Include failed starts and cleanup in the load test's result.
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.