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.
Limits are org-wide unless stated otherwise.
Two things count against the concurrent browser limit 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.
Rate limits
Kernel enforces per-organization rate limits on API requests. Browser creation is rate limited separately from concurrency: the create rate caps how fast you can create browsers, not 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 a rate limit returns429 Too Many Requests. Rate-limited endpoints include these headers on every response:
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 heavy a page one browser can hold. When a browser runs out of memory, the kernel kills a Chromium process and the page fails with
Page crashed or Target crashed. One heavy page can do this on its own — it doesn’t take many tabs. See a crashed page.
Memory is set when the browser is created and can’t be changed on a running browser: headless browsers take 1GiB, 2GiB, or 4GiB, and headful browsers take 8GiB (the default) or 16GiB. Pass memory to create or set it on a browser pool; a pool change applies only to browsers built after it.
If pages are dying, create the browser with more memory, or spread the work across more browsers rather than more tabs in one. To check memory before a page fails, run free -m inside the session and watch available. If it trends toward zero before the page dies, the page’s working set is the problem. See measure memory and CPU usage.
GPU acceleration is a separate browser type with its own usage rate, available on Start-Up and Enterprise.