Skip to main content
Three separate limits shape a scaled workload, and they’re easy to confuse. Concurrency caps how many browsers exist at once. The create rate caps how fast you can ask for new ones. Per-browser resources cap what one browser can do.

Concurrency

One org-wide limit covers every browser you’re running, whether created on demand with browsers.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.
Set per-project caps if you’re splitting one org limit across teams or environments — see project concurrency limits.

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 returns 429 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 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 starts killing renderers. If your workload needs many concurrent pages, spread it across more browsers rather than more tabs in one. Browser pools accept a memory setting when a workload needs more than the default. GPU acceleration is a separate browser type with its own usage rate, available on Start-Up and Enterprise.

Other limits worth knowing