Startup plan accepts 48 jobs, not 50: send 50 AI video clips in waves

Only a Scale workspace can hold 50 paid video jobs at once: accepted capacity is 6 on Free, 24 on Pro, 48 on Startup and 120 on Scale. On a smaller plan the 49th or 25th submit returns 429 queue_full, so send the clips in waves and retry with the same Idempotency-Key when jobs finish.

For 30-second Seedance 2.5 and Wan 3.0 renders the point is more practical than it sounds. Those jobs hold their processing slot for minutes, so the queue stays full for a while and you should plan for it.

Concurrency is not the submit limit

Sume accepts valid jobs as queued while queue capacity remains, and workers move them to processing under the plan's concurrency limit. The default queue capacity is max(3, concurrency_limit x 5), and accepted capacity is concurrency plus queue. Full concurrency alone is not an error; it becomes 429 queue_full only when the queue is also full (Generation admission).

How the wave sizes are computed

wave_size_hint is max(1, floor(queue_capacity_remaining x 0.75)) on an empty workspace, so Free is floor(6 x 0.75) = 4, Pro is 18, Startup is 36, and Scale is 90. Treat it only as a hint for how many to submit together, never as the concurrency limit. The effective concurrency_limit in the generation_limits object is the authority, because admin overrides can differ from the table.

Waves for 50 are ceil(50 / hint). They count submissions, not elapsed time. Sume does not publish a per-job queue position or an ETA, so do not promise one.

What to do on queue_full

• Do not add more work for that workspace.
• Poll your current jobs until at least one is terminal, with backoff.
• Cancel queued jobs you no longer need. Cancel works only before generation starts.
• Retry the rejected submit with the same Idempotency-Key, using retry-after when present.

A bounded submitter

This loop pauses on queue_full, then continues with the same key. It stops cleanly on a 402 instead of looping.

import os, time, requests
H = {"Authorization": "Bearer " + os.environ["SUME_API_KEY"]}

def submit(key, body):
    while True:
        r = requests.post("https://api.sume.com/v1/videos", json=body,
                          headers={**H, "Idempotency-Key": key}, timeout=30)
        if r.status_code == 402:
            raise SystemExit("balance stop: " + r.text)
        if r.status_code == 429:
            time.sleep(float(r.headers.get("retry-after", 30)))
            continue
        r.raise_for_status()
        return r.json()["id"]

ids = [submit(f"promo-v2-{i:02d}", {"model": "wan-3.0", "duration": 30,
       "resolution": "480p", "prompt": f"Scene {i}"}) for i in range(50)]
print(len(ids), "accepted")

Money check

Fifty 30-second Wan 3.0 clips at 480p are $93.75 on Sume, so the balance must cover about that before the first submit. The reservation is taken at accept time, which is why a half-submitted batch can stop on 402 instead of queue_full.

Checking the number you were given

Do not hard-code 48. Read wave_size_hint from the admission information Sume returns and size each wave from it. The hint is the floor of the remaining queue capacity times 0.75, so it changes as your queue drains and as your plan changes.

After each wave, wait for most jobs to finish before you submit the next one. A 429 queue_full is a signal to wait, not to retry in a tight loop, and your submit helper should treat it that way.