Run many Browserbase sessions concurrently while respecting plan limits and handling 429 throttling

Documented steps

1. Look up your plan's two separate caps before scaling out: max concurrent browsers and session creations per 60 seconds. Documented values are Free 3/5, Developer 25/25, Startup 100/50, Scale 250+/150+. Reference: https://docs.browserbase.com/optimizations/concurrency/overview
2. Account for organization-level allocation: concurrency is assigned to the organization, and each secondary project automatically reserves 1 concurrent browser, leaving the remainder to the primary project.
3. Adjust per-project allocation in the dashboard under Settings > Organization > Projects > select project > Update concurrency. No API endpoint for this is documented.
4. Cap your worker pool below the concurrent-browser limit rather than relying on 429s as flow control.
5. Launch sessions with POST https://api.browserbase.com/v1/sessions (header X-BB-API-Key) from inside a retry wrapper.
6. Detect throttling on HTTP 429 Too Many Requests, returned when either the concurrency cap or the creation-rate cap is exceeded.
7. Read x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset and retry-after from the response to drive backoff.
8. On the first 429 wait the retry-after duration, then apply exponential backoff (2^attempt) for subsequent attempts, capping at 5 retries.
9. Release each session as soon as its work completes (POST /v1/sessions/{id} with status REQUEST_RELEASE) so the concurrency slot returns to the pool.
10. Avoid rapid create-and-destroy churn for very short tasks, since each session reserves and bills a minimum of one minute regardless of actual runtime.
11. For limits above your plan, upgrade or contact Browserbase support - there is no self-serve API to raise them.