A $37 wallet: how many seconds of 720p video on each Sume model

At 720p (768p for MiniMax H3, which is native 768p), a $37.00 wallet buys 493 seconds on MiniMax H3 (native 768p) and 64 seconds on Seedance 2.5, a spread of about 7.7 to 1. The whole-clip count matters more than the seconds, because you cannot spend the remainder on a partial clip.

Every figure below is the Sume customer price (provider list x 1.25), run through the price tool on 2026-10-09 for a 10-second 720p job. Seedance rows are 9:16.

Seconds and whole clips for $37

Seconds = $37 divided by the per-second rate, rounded down. Clips = $37 divided by the 10-second price, rounded down. Sorted from cheapest per second.

Same price, different clip

Wan 3.0 and Gemini Omni Flash 1.1 tie at $0.125 per second at 720p ($1.25 versus $1.25 for 10 seconds), so the wallet cannot choose between them; the brief can. Wan 3.0 accepts 2 to 30 seconds, while Omni Flash 1.1 accepts 3 to 10 seconds in 16:9 or 9:16 and always produces synced audio. If your clips are longer than 10 seconds, only the Wan row applies.

The cheapest per-second row is also not automatically the cheapest per finished clip. A model that needs three takes to land costs three times its sticker price, which is why the whole-clip column is the one to budget against. Pair this table with your own acceptance rate before you commit a wallet to one model.

Check your own balance

The balance endpoint returns USD micros, so you can run the same division against the live number instead of a planned top-up. One million micros is one dollar.

import os, requests

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
r = requests.get("https://api.sume.com/v1/balance", headers=H, timeout=30)
r.raise_for_status()
micros = r.json()["data"]["balance"]["available_amount_usd_micros"]
print(f"balance: ${micros / 1_000_000:.2f}")
price_10s_micros = 1_250_000  # Wan 3.0, 720p, 10 s
print(micros // price_10s_micros, "whole Wan 3.0 clips")

How the $37 is actually held

Sume does not bill at the end of a batch. When you submit a job it reserves the estimated amount (provider list x 1.25), and a successful completion captures that reserve. If the job fails or is canceled before capture, the reserve is released. So once 29 accepted Wan 3.0 clips are reserved against $37.00, the spendable balance reads $0.75 whether or not those clips have finished.

That is also why a large batch can 402 on its last few submissions even though earlier clips are still cooking: the later submits find no unreserved balance left.

Gotchas

A job reserves the price at submit, so the spendable balance has to cover the whole clip up front. A wallet with $1.00 left cannot start a $1.25 clip: the submit returns 402 insufficient_credits before any provider work starts.

The 10-second price is a planning number. Other lengths, 1080p, or a different aspect ratio on Seedance change the total; run the estimate per job. Top-ups happen in the dashboard (Billing & subscription); the public API reads balance and usage but does not create a top-up.

• Seedance 2 and 2.5 are token-priced: price depends on resolution, seconds and aspect ratio.
• Concurrency comes from your plan, not from the size of the wallet.
• Read GET /v1/balance before a batch; state: empty means no spendable balance.