Free, Pro, Startup, Scale: processing seats, queue slots, full hold

Sume admits paid generation jobs by plan: Free runs 1 at a time with 5 queue slots, Pro 4 with 20, Startup 8 with 40, and Scale and Enterprise 20 with 100. Queue capacity defaults to max(3, concurrency_limit x 5), and accepted capacity is concurrency plus queue, so a Pro workspace holds 24 paid jobs at once before 429 queue_full.

Concurrency limits dispatch, not submission. A Pro workspace can submit 24 valid jobs in one burst; four run and twenty wait as queued. Generation admission is the source for every number here, and the API's generation_limits field is the live truth if your workspace has an override.

Capacity and worst-case hold

The last column is the reserve if every accepted slot holds a 10-second Wan 3.0 clip at 720p ($1.25 each). Sume reserves each estimate at submit.

Reading the live numbers

Submit responses carry a generation_limits snapshot. The docs size new in-flight work from it:

def headroom(g):
    """New in-flight jobs to add, per the generation-admission docs."""
    free_seats = g["concurrency_limit"] - g["active_generation_jobs"] - g["queued_generation_jobs"]
    return min(max(0, free_seats), g["queue_capacity_remaining"])

snapshot = {"concurrency_limit": 4, "active_generation_jobs": 1,
            "queued_generation_jobs": 0, "queue_capacity_remaining": 23}
print(headroom(snapshot))  # 3

Two traps

• wave_size_hint is a submission hint that includes queue slots. It is not your concurrency, so never size a worker pool from it.
• Concurrency is plan-only: prepaid top-ups do not raise it. Org workspaces have a floor of 10 and Enterprise uses admin overrides.

How to use the table

The hold column is a ceiling, not a typical state. It answers one question: what balance would a worst-case burst reserve? A workspace that has accepted its full capacity of paid jobs has that much set aside until jobs complete, fail or are canceled, so a balance below the figure means some submits in a burst would be refused with 402 insufficient_credits before the queue is even full.

Planning a burst

Take your accepted capacity, multiply by the per-job estimate, and compare with the balance. If the balance is the binding limit, you will see 402s first; if the queue is, you will see 429 queue_full. Either way the right pattern is the same: submit in waves, store each job id, and let finished jobs free room for the next wave. The Python helper above computes how many jobs a wave can add from a live snapshot.