One concurrency slot per JS-rendered request, down from five
View as MarkdownRequests with render=true now count as one concurrent request instead of five, so your plan runs five times as many rendered requests at once.
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 sized 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), you no longer need those workarounds.
Why now
We rearchitected the browser pool 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 for the current rules.
