# One concurrency slot per JS-rendered request, down from five

> Source: https://scrape.do/documentation/changelog/2026-02-03-js-rendering-concurrency/

2026-02-03 · breaking

Requests with `render=true` (and the related `super=true&render=true` combinations) now count as a **single** concurrent request. Previously they consumed five concurrency slots, originally to reserve browser pool capacity.

## What this means

- **Pro plan** — 15 concurrency now lets you run 15 simultaneous rendered requests instead of 3.
- **Business plan** — 40 simultaneous rendered requests instead of 8.
- **Advanced plan** — 200 simultaneous rendered requests instead of 40.

If you were sizing your concurrency around the old accounting — running fewer parallel workers, splitting renders across multiple keys, or queueing rendered jobs through the Async API to avoid hitting the limit — those workarounds are no longer needed.

## Why now

The browser pool was rearchitected so a rendered request no longer occupies a fixed slice of capacity for its full lifetime. Concurrency accounting can match a 1-request-1-slot model again, which is also the model everyone expected.

See the [request costs documentation](/documentation/request-costs) for the current rules.