Free-plan video batch on Sume: six accepted, one renders at a time

On a one-slot plan Sume accepts valid video jobs as queued up to six. What the 7th submit returns and how to pace a batch.

5 min readSume
All posts

On the Free plan, Sume lets you submit six video jobs at once and runs them one after another. The generation admission page lists Free with processing concurrency 1, queue capacity 5, and accepted job capacity 6. Concurrency is a dispatch limit, not a submit limit, so the second to sixth jobs are accepted as queued. A seventh submit with all six still waiting or running fails with 429 queue_full.

That makes the plan good for a small test batch and a poor fit for a launch. This note works through what you can expect to see.

What each submit returns

Assuming six jobs submitted in a row on a Free workspace with enough balance, based on the admission page, read 2026-10-03.

Free plan: concurrency 1, queue 5, accepted capacity 6 (read 2026-10-03)
SubmitAccepted?State it shows
1Yesqueued, then processing as soon as a worker moves it
2 to 6Yesqueued, waiting behind the earlier jobs
7 while all six are activeNo429 queue_full
7 after one job is terminalYesqueued

How to pace the batch

Store each job id and Idempotency-Key as you go. Poll status with backoff and honor next_poll_after_seconds when it is present. When a job reaches completed, failed or canceled, one slot of accepted capacity opens and you can submit the next clip. Do not treat queued as a failure and do not resubmit the same clip because it has waited.

If you hit queue_full, stop adding work, wait for a terminal job, then retry the same request with the same key. Sume releases or refunds the reservation for a failed admission, so the rejected seventh job does not hold balance.

What balance has to cover

Each accepted job reserves its estimated cost on submit, at provider list times 1.25. Six queued jobs hold six reservations at the same time even though only one is rendering. If the balance cannot cover the next reservation, the submit fails with 402 insufficient_credits before provider work starts. So the practical ceiling for a batch is the smaller of accepted capacity and what the balance can reserve.

When to move up

Prepaid top-ups do not raise processing concurrency; it is plan-only, with admin overrides for contract limits. If a six-job batch is routine, compare the next plan's capacity from the same table, and read the live generation_limits on a submit response to confirm what your workspace actually has.

A useful test batch

Six jobs is enough to compare models. Submit the same prompt to three models at two resolutions, record the cost each reserved, and look at the files. That is a better use of the Free plan than six near-identical clips. Name each job with a label in your own records so that the comparison survives a restart.

If you want to try a variant after seeing the results, submit it after one of the six has finished, so that you never meet queue_full in the middle of an experiment.

Limits

The docs do not state how long one clip takes, so this post gives no batch time. They also say to prefer effective fields over the static table, so check your workspace before you plan around these numbers.

Sources

Related posts

More in Pricing

All Pricing posts

Written by Sume