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

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 for the current rules.