Video generation API concurrency: control active jobs across your workers

Video generation API concurrency measures active renders, not how many HTTP requests happen to be open. Genace counts queued and running job rows for the user when checking generation concurrency. Returning from a submission POST therefore does not free a slot: the resulting job can continue occupying capacity for much longer.

The current quota implementation selects one active job for the Free tier and five for an active qualifying subscription. These are repository configuration values, not an assumption that should be buried permanently in your client. Plan conservatively and handle the actual rejection response if account configuration changes.

Separate the two control loops

Request rate controls how quickly your workers call the API. Active-job concurrency controls how much work remains unfinished. A workload can violate either limit independently. One long render can occupy a Free account’s single slot while its request rate stays very low.

Resource	Current scope	Release condition
Request-rate window	API key	Older request events leave the window
Active-generation count	User	Jobs leave queued and running
Your worker execution slot	Your application	Worker completes its local task
Your render permit	Your application	Remote job becomes terminal or is reconciled

Creating additional API keys does not create more user-level generation capacity. Also remember that image and video jobs share the job table’s active-state count in the current implementation. A busy image workload can therefore affect video admission for the same user.

Use durable permits for distributed workers

A process-local semaphore only coordinates one process. If your queue has several workers, use a shared database or queue scheduler to reserve render permits. Save the permit together with the local request record, then attach the returned job_id after acceptance.

receive queued application request
reserve one shared render permit
mark the request as submitting
submit generation once
save returned job_id
schedule status collection
retain permit while state is queued or running
release permit after terminal snapshot is saved

This sequence is a design outline for your application. If submission becomes ambiguous, retain a reconciliation record instead of immediately releasing the permit and sending another render. You need to know whether remote work exists before deciding capacity is available again.

Do not treat admission as a hard reservation guarantee

The current gateway concurrency check counts active rows before submission and does not hold a database lock across admission. Concurrent arrivals can race. Your application should maintain its own conservative dispatch discipline if strict business-level capacity is important, rather than depending on an exact last-slot race outcome.

Common mistakes include releasing a permit when the POST returns, counting only running jobs, and starting multiple independent collectors that each believe they own permit cleanup. Assign one owner for terminal reconciliation and make permit release safe to repeat.

Verification checklist

Simulate two workers claiming the last local permit, a job returning to queued, a terminal failure, and a worker crash after acceptance. Confirm that active jobs continue occupying permits and that terminal handling releases each permit once. Track admission rejections separately from model failures.

Read 429 diagnostics, batch queues, and observability.

Continue with production operations

• AI video API webhook vs polling: which one to use and when
• How to call a video generation API without blocking your agent
• generation operation unique key: deduplicate local intent without inventing API idempotency
• Browse all production operations guides