Seedance 2.5 on Sume's Free plan: 1 running, 5 queued, 6 accepted

On Sume's Free plan a workspace can have 1 generation job processing and 5 waiting, so 6 seedance-2.5 jobs are accepted at once and the seventh submit fails with 429 queue_full. Jobs past the first show queued, which is normal, not an error. Pro takes 24, Startup 48, and Scale and Enterprise 120.

Numbers come from the table in Generation admission, read 2026-10-02, which also says to prefer the live generation_limits field over the static table. Seedance 2.5's 4-30 s range comes from the Video Router docs.

How many Seedance 2.5 jobs can each plan hold?

Concurrency is a dispatch limit, not a submit limit: Sume accepts valid jobs as queued while queue capacity remains, and workers move them to processing under the per-workspace cap. Generation concurrency is plan-only, and prepaid top-ups do not raise it.

What happens to the seventh clip on Free?

Once all accepted capacity is used, new paid submissions fail with 429 queue_full, and Sume releases or refunds the reservation for that failed admission. The docs tell you to stop adding work, poll existing jobs until one is terminal, cancel queued jobs you no longer need, then retry with the same Idempotency-Key.

Each accepted submit response includes generation_limits with queue_capacity_remaining and a wave_size_hint, defined as max(1, floor(queue_capacity_remaining * 0.75)). The docs call it a submission-wave hint only, not a concurrency limit. On an empty Free workspace it works out to 4.

How should I pace a Seedance 2.5 batch?

Use the headroom rule from the docs: concurrency_limit minus active minus queued jobs, capped by queue_capacity_remaining, is the budget for new in-flight work. On Free with nothing running that budget is 1, so submit one, wait for it to finish, then submit the next. Queue slots can absorb more, but the docs call that a separate admission policy, not a pacing target.

Seedance clips can run up to 30 seconds, and at that length a batch of 12 clips on Free takes several waves. If you need volume, the cheaper lever is a higher plan, since concurrency is plan-only. See also batch limits and wave size.

If you do use the queue on Free, stay well under 6 accepted jobs so a retry still fits and queue_full stays away. Do not treat wave_size_hint as a concurrency number; the docs say never to use it to size in-flight work.