Does a bigger top-up raise Sume video concurrency? No, the plan does

No. Sume's generation concurrency is plan-only: prepaid top-ups do not increase the number of jobs that process at once. A bigger wallet only changes whether 402 insufficient_credits fires; the plan decides whether 429 queue_full fires.

With 20 Wan 3.0 clips of 10 seconds at 720p ($1.25 each) on a Free workspace, the wallet could be $500 and Sume would still accept only 6 jobs at a time: 1 processing and 5 queued. The other 14 submits return 429 queue_full.

What each plan holds

Figures from the generation admission page (read 2026-10-09). Accepted capacity is processing concurrency plus the default queue capacity, which is max(3, concurrency x 5). The last column is the balance you need reserved to fill the whole accepted capacity with $1.25 Wan 3.0 clips (accepted jobs x $1.25).

Which error means which

The two errors look similar in a batch loop and need opposite fixes. Do not top up to fix a queue error, and do not wait to fix a balance error.

Handle both in code

Treat queued as normal, not as a failure. Only stop submitting when the queue is full, and store the idempotency key so the retry returns the original job instead of a second charge.

import os, requests

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
BODY = {"model": "wan-3.0", "prompt": "Slow pan across a tidy desk",
        "resolution": "720p", "duration": 10}

def submit(i):
    h = {**H, "Idempotency-Key": f"promo-{i:03d}"}
    r = requests.post("https://api.sume.com/v1/videos", headers=h, json=BODY, timeout=60)
    if r.status_code == 402:
        return "add funds"
    if r.status_code == 429:
        return r.json()["error"]["code"]  # queue_full or rate_limited
    r.raise_for_status()
    return r.json()["id"]

print([submit(i) for i in range(8)])

What a top-up does buy

A top-up buys the ability to reserve. Filling a Pro workspace's 24 accepted slots with $1.25 clips needs $30.00 reserved at once, so anything above that is spendable later but does not make the first wave faster. On Free the reserve to fill is $7.50.

To get more parallel throughput you change the plan (or, for large contracts, an admin override on the workspace). The documented way to pace a client is to read generation_limits from the submit response and use max(0, concurrency_limit - active_generation_jobs - queued_generation_jobs) as the budget for new in-flight work. The docs' own example: with a limit of 100, 30 processing jobs and 10 queued jobs leave a budget of 60.

Top-ups themselves are a dashboard step: Billing & subscription starts a Stripe-backed manual top-up when billing is configured, and the public API only reads balance and usage.

Gotchas

• The Concurrency tab in the dashboard is the source of truth; the table above is a default and admin overrides can raise it.
• Organization workspaces have a floor of 10, and Enterprise defaults to 20.
• Submit responses can include generation_limits with queue_capacity_remaining; use it to size the next wave instead of guessing.