​
Key Limits

Browser automation becomes powerful when you can run multiple browser sessions simultaneously. Whether you’re scraping data at scale, running parallel tests, or serving multiple users, understanding concurrency and rate limits is critical.

To ensure system stability and fair resource allocation, two key limits apply:

  • Concurrent Limit: The maximum number of browser sessions that you can run at the same time
  • Rate Limit: The maximum number of new browser sessions you can create within any 60-second period

If either limit is reached, your request will receive a 429 (too many requests) error.

One Minute Minimum: each browser session requires dedicated resources and has a minimum runtime of one minute, even if closed before.

​
Limits by Plan

These limits depends on your plan:

PlanFreeHobbyStartupScale
Concurrent limit1350100+
Rate limit1350100+

​
Limits and Concurrency per Project

If you created your Browserbase account after May 4th, 2025, you’ll have the option to create multiple projects within your Browserbase Organization. This is available for Hobby, Startup, and Scale Plan users (not Free).

Concurrency is assigned to the Organization level - so if you’re on the Hobby plan, you have 3 total concurrent browsers allotted to your Organization, to be distributed to your projects.

With one project, all concurrent browsers simply go to that one project. When you create a second project, 1 concurrent browser is automatically added to your second project (since you need at least one browser per project). This subtracts from your first project.

If you have two projects, here’s how the concurrency will assign by default:

  • Hobby plan: Project 1 (2 browsers) + Project 2 (1 browser)
  • Startup plan: Project 1 (49 browsers) + Project 2 (1 browser)
  • Scale plan: Fully custom

If you would like more than 1 browser allotted to your second project, just send us a note through the Pylon widget in the dashboard or at support@browserbase.com. We’re actively working on making this distribution self-serve!

​
Reaching Limits: 429s

When reaching the session concurrency limit of your plan, any subsequent request to create a new session will return an HTTP 429 Too Many Requests error. That means the request was effectively dropped.

For example, if you have a Hobby plan (with a limit of 3 concurrent sessions) you can create up to 3 sessions in a 60 second window. If you try to create a 4th session within that window, it will be rate limited and return an HTTP 429 error.

To check the status of your rate limit, you can look at the headers of the response:

  • x-ratelimit-limit - How many requests you can make.
  • x-ratelimit-remaining - How many requests remain in the time window.
  • x-ratelimit-reset - How many seconds must pass before the rate limit resets.
  • retry-after - If the max has been reached, this is the number of seconds you must wait before you can make another request. This is documented here.
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
x-ratelimit-limit: 3
x-ratelimit-remaining: 0
x-ratelimit-reset: 45
retry-after: 45

​
Avoiding Rate Limits

To avoid rate limits, you can either run fewer concurrent sessions or close sessions explicitly - as opposed to letting them time out.

For production systems, consider implementing retry logic that respects these headers, using exponential backoff and circuit breakers to handle high concurrency.

If you need more concurrency, you can upgrade to a plan that allows for a higher limits. See Plans & Pricing for more details. Or reach out to us at support@browserbase.com with any questions.