Batch of 30-second Seedance clips: Pro, Startup and Scale queues

On the Pro plan a Sume workspace can hold 24 paid generation jobs at once: 4 processing and up to 20 queued. A 25th Seedance 2.5 submit fails with 429 queue_full until one finishes or is canceled. Startup holds 48, Scale 120. These are the limits for any paid generation job, so a batch of 30-second seedance-2.5 clips follows the same rule, and the table below tells you how big a batch you can submit in one go.

What are the limits per plan?

Generation admission separates four controls: processing concurrency, queue capacity, submit rate limits and balance. Concurrency is plan-only; prepaid top-ups do not raise it. Queue capacity defaults to max(3, concurrency_limit × 5), and accepted capacity is concurrency plus queue.

What happens when you submit 40 clips on Pro?

The first 4 start processing, the next 20 sit in queued, and the remaining 16 fail with 429 queue_full before provider work starts. Queued is not a failure: the doc says to store the job id, poll status with backoff and fetch the result when status is completed or result_ready is true.

There are two other refusals to expect in a batch. 402 insufficient_credits means the workspace balance cannot cover the reserve for the request, and 429 rate_limited means too many submit requests in the window; the errors doc says to back off using retry-after when present and never to retry a submit without an Idempotency-Key.

Org workspaces have a floor of 10 and admin overrides can raise a limit, so the plan table is a default. Read the effective generation_limits.concurrency_limit from the API instead.

Why does the vendor's concurrency claim not change this?

The BytePlus Seedance 2.5 page (read 2026-10-03) says the model is "built for high-concurrency API usage". That describes the vendor's own service. On Sume your cap is your plan's cap, because jobs are admitted per workspace before they reach a provider. A bigger batch needs a bigger plan or a wave-by-wave submit, not a faster model.

What is a safe submit loop?

Give each clip its own Idempotency-Key, so a retry after a network error returns the original job and does not queue a second one. On 429 wait for retry-after and send the same key again. Stop the loop at 402. The doc's /v1/videos request takes model, prompt, duration, resolution and aspect_ratio.

import os, time, requests

URL = "https://api.sume.com/v1/videos"
AUTH = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}


def submit(i, prompt):
    body = {"model": "seedance-2.5", "prompt": prompt,
            "duration": 30, "resolution": "480p"}
    headers = {**AUTH, "Idempotency-Key": f"batch-clip-{i}"}
    for _ in range(5):
        r = requests.post(URL, headers=headers, json=body)
        if r.status_code != 429:
            return r
        time.sleep(int(r.headers.get("retry-after", 30)))
    return r


for i, p in enumerate(["a lighthouse at dusk", "a market in the rain"]):
    r = submit(i, p)
    print(i, r.status_code, r.json().get("id"))
    if r.status_code == 402:
        break

How do you follow a batch?

Job statuses on the /v1/videos route are pending, in_progress, completed, failed and cancelled; the same job is also visible at GET /v1/jobs/{id}/status with the queued, processing, completed, failed, canceled vocabulary of the admission doc. Pick one view and stay with it so your code does not mix the two spellings.

Instead of polling every job, pass callback_url (HTTPS only) and Sume posts to it when the job reaches a terminal state, signed with x-sume-webhook-signature. Poll as a fallback for any job whose callback does not arrive. The errors doc lists 409 codes job_not_cancelable and job_generation_already_started for operations that no longer fit a job's status, so do not assume a started job can be canceled.

How should you size a batch?

Count clips against accepted capacity, not processing concurrency. A 24-clip batch fits Pro in one submit; a 100-clip batch fits Scale in one submit but needs about four waves on Pro. Poll with backoff, and submit the next wave as results complete. The Video Router doc notes that limits are per model, so check GET /v1/video-router/models for the model you pin before you size a batch of 30-second clips.