Video job stuck in queued on Sume: limits by plan and queue_full

The short answer

An image-to-video job that sits in queued is waiting for a concurrency slot, not failing. Sume processes 1 generation at a time on Free, 4 on Pro, 8 on Startup and 20 on Scale. Extra valid jobs queue until a slot opens. Only a full queue returns 429 queue_full, and a missing balance returns 402 insufficient_credits.

What queued means

Concurrency is a dispatch limit, not a submit limit. A workspace at its limit can still accept more jobs as queued while queue capacity remains. The lifecycle is queued, then processing, then completed, failed or canceled. Store the job id, poll with backoff and fetch the result only when the job is complete.

Limits by plan

Defaults per plan, from the admission docs. The dashboard Concurrency tab and the generation_limits field in the submit response show your effective numbers, and they are the source of truth.

What does not change it

Prepaid top-ups do not raise the processing limit. It follows the plan.

Reading the status

On /v1/videos, the polling status reads pending before the job runs and in_progress while it runs, then completed, failed or cancelled. The job envelope at GET /v1/jobs/{id}/status shows the queued and processing stages. Send the Idempotency-Key on every submit so a retry does not make a second job.

curl https://api.sume.com/v1/jobs/$JOB_ID/status \
  -H "Authorization: Bearer $SUME_API_KEY"

Batches and queue_full

If a batch of 40 jobs hits a Pro workspace, 4 run, 20 wait, and the other 16 fail with 429 queue_full. Submit in waves instead. The generation_limits block in a submit response includes queue_capacity_remaining and a wave_size_hint, so use them to size the next wave. On queue_full, wait for jobs to finish, or cancel queued ones, then retry with the same idempotency key.