What a 30-second Wan 3.0 job reserves on Sume: list times 1.25

How much does Sume reserve for a 30-second Wan 3.0 clip at 720p?

$3.75. The catalog's list price for wan-3.0 at 720p is $0.10 per second, so 30 seconds is $3.00, and Sume reserves the list price times 1.25 at submit. If the balance cannot cover that hold the API answers 402 insufficient_credits before any provider work starts. Where applicable, a failed job releases or refunds the reservation.

List prices are in the catalog with the date they were set, and they are subject to change. The Wan figures below are the catalog's list of 2026-08-24, and the Omni and MiniMax rows use the dates shown. Read the current catalog before you hard-code a number in a budget.

Worked examples

Each reserve is list price per second, times seconds, times 1.25, rounded up to the next cent.

Compute it before you submit

Use Decimal, not floats, so the rounding up is exact.

from decimal import Decimal, ROUND_CEILING

LIST = {  # USD per second, from the catalog's dated list prices
    ("wan-3.0", "720p"): Decimal("0.10"),
    ("wan-3.0", "1080p"): Decimal("0.20"),
    ("gemini-omni-flash-1.1", "1080p"): Decimal("0.15"),
    ("gemini-omni-flash-1.1", "4K"): Decimal("0.30"),
    ("minimax-h3-max", "1080p"): Decimal("0.16"),
}

def reserve(model: str, resolution: str, seconds: int) -> Decimal:
    raw = LIST[(model, resolution)] * seconds * Decimal("1.25")
    return raw.quantize(Decimal("0.01"), rounding=ROUND_CEILING)

for key, secs in [(("wan-3.0", "720p"), 30), (("wan-3.0", "1080p"), 30),
                  (("gemini-omni-flash-1.1", "1080p"), 10), (("minimax-h3-max", "1080p"), 15)]:
    print(key, secs, reserve(*key, secs))

Reserve is not the final charge

The reservation is an estimate held against your balance. usage.cost on a finished /v1/videos job is the billable amount, and GET /v1/usage is the ledger. A batch of ten 30-second 1080p clips holds $75 at once, which is a reason to check GET /v1/balance before a batch and to size waves to your plan's queue.

The same arithmetic shows why a 480p draft is a cheap test of a 1080p prompt on the same model: the seconds are the same and the list rate is lower. Run the draft first, then spend on the final.

For a rough budget, multiply the reserve by the number of clips in flight, not only the number you plan to keep. Your plan caps how many jobs run and queue at once, and every accepted job holds its own reserve until it finishes or fails. The docs say failed jobs release or refund their reservation where applicable, so check your balance after a failure instead of assuming.

Keep the list prices in one table in your code with the date each was read, and refresh it when the catalog changes. A stale number is the usual way a budget check drifts away from what the API actually holds.