Wan 3.0 with no resolution sent: priced as 1080p, $1.25 for 5 seconds

Sume's pricing code treats a missing Wan 3.0 resolution as 1080p and a missing duration as 5 seconds. That is $1.25, four times the 480p price.

4 min readSume
All posts

Short answer

If you send a Wan 3.0 request without resolution, Sume's pricing normalizer fills in 1080p, and without a duration it fills in 5 seconds. At Sume's Wan 3.0 rate of $0.25 a second at 1080p that is $1.25 reserved. The same clip at 480p is $0.3125. The savings from stating the resolution is a factor of four.

This comes from Sume's pricing constants rather than a docs sentence, so treat it as the reserve you should expect, and confirm in GET /v1/videos/models and in the reserved ledger row. The Alibaba Wan 3.0 README (read 2026-10-05) lists no prices, so the rates here are Sume's own table.

The three rows

A Wan 3.0 job on Sume is 2 to 30 seconds. The table prices the 5-second default and one second at each resolution.

Wan 3.0 on Sume (list x 1.25; read 2026-10-05)
Resolution5 seconds (default length)Per second
480p$0.3125$0.0625
720p$0.625$0.125
1080p$1.25$0.25

Why it matters

A 402 is the first symptom. The estimate is reserved at submit, so a request with no resolution reserves the 1080p amount even if you meant a quick test. On a wallet with a few dollars left, a 30-second job with defaults reserves $7.50 and fails with 402 insufficient_credits, while the same duration at 480p would have been $1.875.

Defensive request

Always send the resolution and duration you intend.

curl -X POST https://api.sume.com/v1/video-router/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: wan-explicit-001" \
  -d '{"model":"wan-3.0","prompt":"A courier bike on wet asphalt","resolution":"480p","duration":5,"mode":"async"}'

Checklist

  • Put resolution and duration in every Wan request.
  • Read the reserved row after submit and compare it with your budget.
  • Cancel before generation starts if the reserve is wrong; cancel after start returns 409.

How to verify the default yourself

Do a one-line experiment. Submit a 2-second Wan job with no resolution, then read the usage rows and see which amount was reserved. If it is $0.50, the pricing code assumed 1080p (2 x $0.25). If it is $0.125, it assumed 480p. Cancel before generation starts if you do not want the job to run; the docs say cancel succeeds only before generation work starts.

Because the reserve is released on cancel, the experiment costs nothing if the cancel arrives in time. If the job has started, the cancel returns 409 job_generation_already_started and the job completes normally.

A hundred jobs at 5 seconds with the default 1080p reserve $125.00, while the same hundred at 480p would reserve $31.25. A mistake in a template therefore shows up in the wallet immediately. A quick check of the first reserve in the ledger is the cheapest defense.

The defensive habit is simple and cheap: always send the resolution you want. A request that names 720p reserves $0.50 for 5 seconds of Wan at the 720p rate of $0.10 a second times 1.25, with no room for a default to surprise you. A request that omits it relies on whatever the pricing code assumes, and as the table shows, that assumption is the most expensive row.

If you maintain a shared client library, make the resolution a required argument rather than an optional one. It turns a silent default into a visible choice at the call site, and review catches it.

Here is the arithmetic once more for a 5-second job: at 480p the rate is $0.0625 a second for $0.3125, at 720p it is $0.125 a second for $0.625, and at 1080p it is $0.25 a second for $1.25. The ratios are one, two and four, so the default is the row where an unintended choice costs four times the cheapest one. Name the resolution explicitly and the number you budget is the number that is held.

Sources

Related posts

More in Pricing

All Pricing posts

Written by Sume