> ## Documentation Index > Fetch the complete documentation index at: https://www.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](https://www.kernel.sh/docs/browsers/pools.md). 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](https://www.kernel.sh/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](https://www.kernel.sh/docs/info/projects.md#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](https://www.kernel.sh/docs/browsers/pools.md) 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 | | - | - | - | | Memory | 8 GB or 16 GB | 1 GB, 2 GB, or 4 GB | 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](https://www.kernel.sh/docs/browsers/playwright-execution.md#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](https://www.kernel.sh/docs/api-reference/browsers/create-a-browser-session.md) or set it on a [browser pool](https://www.kernel.sh/docs/browsers/pools.md); 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](https://www.kernel.sh/docs/browsers/process-execution.md#measure-memory-and-cpu-usage). [GPU acceleration](https://www.kernel.sh/docs/browsers/gpu-acceleration) is a separate browser type with its own [usage rate](https://www.kernel.sh/docs/info/pricing.md#usage-rates), available on Start-Up and Enterprise. ## Other limits worth knowing | Limit | Where | | - | - | | Browser `timeout_seconds` (default 60, max 259200 / 72h) | [Termination](https://www.kernel.sh/docs/browsers/termination) | | Pool `timeout_seconds` (default 600) and fill rate | [Browser pools](https://www.kernel.sh/docs/browsers/pools.md) | | How managed auth health checks run | [Connection lifecycle](https://www.kernel.sh/docs/auth/connection-lifecycle.md) | | Replay retention, extensions, projects, per plan | [Pricing](https://www.kernel.sh/docs/info/pricing.md#managed-infrastructure) | | Monthly spend | [Spending caps](https://www.kernel.sh/docs/info/spending-caps.md) | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.