Concurrency
One org-wide limit covers every browser you’re running, whether created on demand withbrowsers.create() or reserved in a browser pool. The full limit is available to either API in any mix.
Two things count against it that people don’t expect:
- Reserved pool capacity counts whether or not it’s acquired. A pool sized to 40 browsers uses 40 of your limit for as long as it exists.
- Browsers in standby count. Standby stops usage charges, not the concurrency slot. Delete the browser to release it.
Create rate
Browser creation is separately rate limited per plan. This caps how fast you can create browsers, independent of how many you may run:
Acquiring from a browser pool isn’t subject to the create rate — the pool’s browsers already exist. If your traffic arrives in bursts, that’s the reason to use a pool even when your concurrency headroom is fine.
What happens at the limit
Exceeding the create rate returns429 Too Many Requests with a Retry-After header, and rate-limited responses carry X-RateLimit-Limit and X-RateLimit-Remaining.
All Kernel SDKs retry a 429 up to 2 times, honoring Retry-After. If retries are exhausted, the SDK raises a typed RateLimitError carrying the response headers, so you can apply your own backoff. Queue on your side rather than tightening the retry loop: a 429 means the org is over budget for the minute, so retrying faster doesn’t help.
If you’re hitting the ceiling in normal operation, contact us — the limit is raisable.
Per-browser resources
Memory is the practical ceiling on how many tabs and how heavy a page one browser handles. A headless browser at 1 GB is sized for short-lived, single-page, high-concurrency automation; open a dozen heavy tabs in one and Chromium will start killing renderers. If your workload wants many concurrent pages, spread it across more browsers — that’s what concurrency is for — rather than more tabs in one.
GPU acceleration is a separate browser type with its own usage rate, available on Start-Up and Enterprise.