> ## Documentation Index
> Fetch the complete documentation index at: https://kernel.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Concurrency and Limits

> How many browsers you can run, how fast you can create them, and what each one gets

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](/docs/browsers/pools). The full limit is available to either API in any mix.

| Limit | Developer | Hobbyist | Start-Up | Enterprise |
| - | - | - | - | - |
| Concurrent browsers | 5 | 10 | 150 | Custom |
| App invocations | 5 | 10 | 50 | Custom |
| App invocations (per app) | 5 | 10 | 20 | Custom |
| Managed auth health check interval | 6 hours minimum | 1 hour minimum | 20 minutes minimum | Custom |

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](/docs/browsers/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](/docs/info/projects#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](/docs/browsers/pools) 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:

| Header | Description |
| - | - |
| `X-RateLimit-Limit` | Maximum requests allowed per minute |
| `X-RateLimit-Remaining` | Requests remaining in the current window |
| `Retry-After` | Seconds to wait before retrying (only on `429` responses) |

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](https://calendly.com/d/d3tn-5kp-5yt) — the limit is raisable.

## Per-browser resources

| Resource | Headful | Headless |
| - | - | - |
| Default memory | 8 GB | 1 GB |

Memory is the practical ceiling on how many tabs and how heavy a page one browser handles. A [headless](/docs/browsers/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. Headful browsers support up to 16 GB: set `memory` on a [browser pool](/docs/browsers/pools) when a workload needs more than the default.

[GPU acceleration](/docs/browsers/gpu-acceleration) is a separate browser type with its own [usage rate](/docs/info/pricing#usage-rates), available on Start-Up and Enterprise.

## Other limits worth knowing

| Limit | Where |
| - | - |
| Browser `timeout_seconds` (default 60, max 259200 / 72h) | [Termination](/docs/browsers/termination) |
| Pool `timeout_seconds` (default 600) and fill rate | [Browser pools](/docs/browsers/pools) |
| How managed auth health checks run | [Connection lifecycle](/docs/auth/connection-lifecycle) |
| Replay retention, extensions, projects, per plan | [Pricing](/docs/info/pricing#managed-infrastructure) |
| Monthly spend | [Spending caps](/docs/info/spending-caps) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.