Submit as many jobs as you want
Submitting past your plan's concurrency no longer fails. Jobs are accepted into a queue and run at your plan's concurrency, draining in order as earlier jobs finish.
Submitting more jobs than your plan’s concurrency used to return 429 Concurrent job limit reached, so you had to poll and resubmit. Now every job is accepted. Jobs beyond your running slots wait in a queue and start automatically, oldest first, as the ones ahead of them finish.
Your plan’s concurrency is now a throughput setting, not a submission cap. Free runs one job at a time, Pro runs twenty, and either plan can hold a large backlog of queued work. A submit is only rejected when your balance is zero (402 INSUFFICIENT_CREDITS) or the queue is genuinely full (429 QUEUE_FULL, well above normal use).
Queued jobs show as waiting on the API and as a “Queued” state in the dashboard, then move to running on their own. No client changes are needed. If you were catching the concurrency 429 and backing off, you can drop that retry loop.
Per-plan concurrency is listed under plan limits, and both rejection codes are in error codes.