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. non-gpu browsers support 2GiB or 4GiB headless, or 16GiB headful: set memory when you create a browser or browser pool for workloads that need 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