Job Lifecycle NotesField notes on the Wan 3.0 video API — sourced, dated, and corrected in public.

Four clips in one request is one prompt, not four attempts

Wan 3.0 accepts a request for up to four clips. The number is easy to misread, and the two readings lead to completely different products.

The wrong reading: four attempts at the same shot, so you can pick the best one — a cheap way to buy variance, the way you would sample a language model four times at temperature and keep the good completion.

What it actually is: one prompt, one submission, one place on your concurrency budget, returning four outputs. You are not getting four independent tries at a problem. You are getting one job whose output happens to be a set.

Why the distinction costs money

The concurrency limit is two tasks at once, and there is no way to cancel one. Those two facts combine with the batch size in a way that is not obvious until you have a queue:

• A four-clip request occupies one of your two slots, not four. That is the argument for batching — if you want four outputs, asking for them together leaves a slot free, whereas four separate submissions queue behind each other two at a time.
• But a four-clip request is also uncancellable as a unit. If you realise after ten seconds that the prompt has a typo, you cannot kill it, and you cannot kill part of it. You wait for all four and you pay for all four.

So batching trades throughput for granularity. That is a real trade, and which side you want depends on something specific: how confident are you in the prompt at submission time?

A rule that has held up

• Prompt is settled, you want coverage — batch. Storyboard approved, you need four takes of a known-good shot to cut between. Batching is strictly better here: fewer round trips, one slot, one bill to reconcile.
• Prompt is exploratory — do not batch. Send one, look at it, change the prompt, send another. Four clips of a prompt that turns out to be wrong is four times the wrong thing, and you could not stop it.

The failure mode I have watched people walk into is using the batch as a substitute for iteration: asking for four because they are unsure, when being unsure is precisely the case where four is the expensive choice. Sampling four times is a good instinct borrowed from text generation, where a retry costs a fraction of a cent and returns in a second. It transfers badly to a medium where one output is seconds of wall-clock time and a per-second charge.

The part that is genuinely useful

Where batching earns its keep is consistency, not variance. Four clips from one request share the prompt exactly — there is no chance of a stray edit between submissions, no risk that you changed a word and forgot. When you are assembling a sequence that has to feel like one piece, that guarantee is worth more than the round-trip saving.

The numbers behind this

Clips per request, the concurrency limit, and the absence of a cancel call are all published parameters, not inferences. They are listed with sources and check dates on the Wan 3.0 specification table, alongside the ones that get misquoted most often — there is no 4K tier, no 21:9 ratio, and the output is 30 fps rather than 24.

Disclosure: this site is written by the people who run a third-party browser interface to this model. We are not affiliated with Alibaba or Alibaba Cloud.