Seedance 2.5 price calculator in Python: tokens to dollars

Seedance 2.5 on Sume is billed by tokens, not seconds, so the price of a clip depends on its frame size as well as its length. A short function can estimate it before you submit, so a script can refuse to send a request that would cost more than you meant to spend.

The formula is: width x height x seconds x 24 frames per second, divided by 1,024, gives tokens. Tokens divided by 1,000 and multiplied by the rate gives micro-dollars. Sume's billed rates read on 2026-10-03 are $0.02675 per 1,000 tokens at 480p and 720p and $0.02925 at 1080p.

What does the code look like?

The function below covers the two common aspect ratios at each resolution. Two assertions check it against amounts Sume's own test fixtures record: 8,667,000 micro-dollars for a 15-second 720p 9:16 clip and 42,646,500 for a 30-second 1080p 16:9 clip.

Other frame sizes (1:1, 4:3, 3:4, 21:9) use their own pixel dimensions and can be added to the table.

SIZES = {  # width, height at 16:9 and 9:16 for each resolution
    ("480p", "16:9"): (864, 496), ("480p", "9:16"): (496, 864),
    ("720p", "16:9"): (1280, 720), ("720p", "9:16"): (720, 1280),
    ("1080p", "16:9"): (1920, 1080), ("1080p", "9:16"): (1080, 1920),
}
RATE = {"480p": 26_750, "720p": 26_750, "1080p": 29_250}  # micro-USD per 1,000 tokens

def seedance_25_micros(resolution, ratio, seconds):
    w, h = SIZES[(resolution, ratio)]
    tokens = w * h * seconds * 24 / 1024
    return round(tokens * RATE[resolution] / 1000)

assert seedance_25_micros("720p", "9:16", 15) == 8_667_000
assert seedance_25_micros("1080p", "16:9", 30) == 42_646_500
for res in ("480p", "720p", "1080p"):
    cost = seedance_25_micros(res, "9:16", 10) / 1_000_000
    print(f"{res}: ${cost:.2f} for 10 s")

What does it print?

Run as written, the script prints the price of a 10-second vertical clip at each resolution:

• 480p: $2.69 for 10 s
• 720p: $5.78 for 10 s
• 1080p: $14.22 for 10 s

What are its limits?

It is an estimator, not a quote. The amount a job really reserves is the one the API computes at submit, and the code does not know about future rate changes. Use it as a guard: compare its result to your cap and skip the call when it is above.

The step from 720p to 1080p changes the rate, not only the pixels, which is why 1080p costs so much more per second. The rate-step post shows the per-second figures.

Remember that a job whose reserve cannot be held fails with 402 insufficient_credits before any work starts, and a failed job is refunded.