Why a Wan 3.0 generation fails, and which failures cost you money

Six things can go wrong between pressing generate on a Wan 3.0 job and having a file. Two of them are rejections you caused and can fix in about ten seconds. Three are the model's problem and, on every provider whose terms we can read, cost nothing. One sits in between, gets refunded far less reliably than the others, and is the reason this article exists.

The taxonomy matters more than the error codes, because the useful question is never "what does InvalidParameter mean." It is "am I paying for that."

The failure semantics below come from the Wan 3.0 API reference and the create-task schema, which is where the mutual-exclusion rule and the 24-hour task_id lifetime are written down. Read 2026-08-25.

The rejection that catches nearly everyone

Wan 3.0 accepts two families of input and refuses to take both at once. Send one from each and the job dies before it starts, with this:

{
  "code": "InvalidParameter",
  "message": "The two modes are mutually exclusive. Do not pass reference_xx and first_frame/last_frame at the same time."
}

The reference family is reference_image, reference_video, reference_audio, file and link. The keyframe family is first_frame and last_frame. The split is not arbitrary and it is not a bug to route around. They describe two different jobs. Keyframes say the picture starts here and ends there, invent the middle. References say here is a cast and a mood, work out the shot yourself. A single pass cannot be strictly pinned at both ends and freely composed from a pile of material.

So the fix is a decision, not a workaround. If the opening image is non-negotiable, that is image-to-video and your references have to become words in the prompt. If the cast is non-negotiable, that is reference-to-video and you describe the opening instead of uploading it.

Two smaller versions of the same rule: file and link are also mutually exclusive — one document or one URL, never both — and there is exactly one of each per job.

Assets rejected on spec

The second rejection is dimensional. Every limit below comes from the Wan 3.0 API reference, checked 2026-08-25.

Three of these produce rejections that read as mysterious until you know them. PNG transparency is not supported — a logo on a transparent background is a common and confusing failure. Wan 3.0 reads the 15-second ceilings as totals rather than per clip, so five three-second references are fine and two ten-second ones are not. And 50 pages is a hard page count, not an approximation of file size; a 40 MB, 80-page deck fails on pages while passing on megabytes.

Three that do not look like failures at all

These return a perfectly good video that is not the one you asked for, which is worse than an error because you pay for it and then argue with yourself about the prompt.

Your prompt was truncated silently. The ceiling is 20,000 characters and anything past it is cut without warning. That is a generous budget — roughly 3,000 words — so it rarely bites, but when it does there is no error to read.

Your prompt was rewritten. Wan 3.0 ships with prompt expansion on by default. It genuinely helps a short prompt and it genuinely interferes with a long one you have already tuned, and the response hands back the original text under orig_prompt so you can see what you sent versus what ran.

Your resolution defaulted to the most expensive tier. If resolution is not set, Wan 3.0 generates at 1080P. That is four times the per-second rate of 480P. Nothing errors, nothing warns, and the difference on a thirty-second clip is $1.50 against $6.00 at Alibaba's published rates. Of everything on this page, this is the one that has quietly cost people the most money, and it is one parameter.

UNKNOWN is not a failure. It is a receipt you threw away

Wan 3.0 reports six task states: PENDING, RUNNING, SUCCEEDED, FAILED, CANCELED and UNKNOWN. The last one is not a generation problem at all. A Wan 3.0 task_id is valid for 24 hours; query it after that and the system no longer knows what you are talking about.

This is the leaky state, for a reason worth being explicit about: a job that returns UNKNOWN may well have succeeded. Nobody was there to collect it. That makes it awkward to classify — it is not a model failure, so automatic refund rules written around FAILED do not catch it, and at least one provider documents UNKNOWN as landing in manual reconciliation rather than an automatic refund.

Two consequences. Front-ends that map UNKNOWN onto PENDING will spin forever, so if you have ever watched a progress indicator run past an hour, this is probably what you were watching. And the honest label is "expired," not "failed" — different cause, different remedy, and you deserve to be told which one happened.

The second 24-hour clock is the one that catches people who did everything right. video_url also expires 24 hours after the job succeeds. The file is generated, the money is spent, and if nobody downloaded it, it is gone. Any service worth using copies the output to its own storage on completion. If you are calling Wan 3.0 yourself, that copy is your job and it is the single most important line in the integration.

Queueing is not failing, though it looks the same at 4pm

Wan 3.0 runs 2 concurrent tasks with a 50-task queue and a submission ceiling of 30 requests per minute. A single generation typically takes one to five minutes, and longer clips take longer.

Those numbers are small enough to be worth planning around rather than discovering. Batch four variants and you are running two and waiting on two, not running four. Nothing has failed; the third and fourth are queued. Meanwhile the published API reference has no cancel call — the CANCELED state exists in the enum, but there is no documented way for you to put a task into it, and at least one provider states plainly that Wan 3.0 tasks cannot be cancelled. Once a thirty-second 1080P job is submitted, it is submitted.

The expensive failure is the one that worked

Everything above is recoverable in seconds and, in most billing regimes, free. The one that empties an account is the Wan 3.0 generation that completes exactly as specified and is still unusable — wrong tone, hands, a face that drifts at second twenty, a reference the model interpreted as a suggestion.

That gets billed, and it should. Compute was spent. It is also the overwhelming majority of what people spend money on: three to five attempts per keeper is the working assumption across this whole category, and it is not a Wan 3.0 problem.

Which is why the resolution default above matters more than any error code on this page. Four attempts at thirty seconds costs $6.00 at 480P or $24.00 at 1080P on Alibaba's published list price, for the same number of learnings. The full arithmetic is in the cost article; the short version is that drafting cheap is not a compromise, because it is the identical model at every tier.

What to demand from whatever you are using

Five of the six failures above are settled by the software in front of the model rather than by the model. That makes them a fair thing to judge a service on — so here is the list as questions, with where this one stands on each.

What none of that changes is the attempt ratio. It is the same Wan 3.0 model everywhere, and three to five goes per keeper is the honest number on any service you pick. The difference is entirely in what the software does with the goes you throw away — and on a thirty-second 1080P brief at list price, the discarded attempts are $18.00 of the $24.00. That is the part worth shopping for.

Nine checks before you press generate

1. One family only — references or keyframes, never both.
2. One file or one link, not both.
3. resolution set explicitly. The default is the expensive one.
4. Every image between 240 and 8000 px, under 20 MB, no transparency.
5. Reference video clips totalling 15 seconds or less.
6. Reference audio clips totalling 15 seconds or less.
7. Documents at 50 pages or fewer.
8. Prompt under 20,000 characters, and prompt expansion off if you tuned it.
9. Somewhere for the file to go before the link expires in 24 hours.

Questions

Am I charged when a Wan 3.0 generation fails?

You should not be, and here it is refunded automatically without a ticket. Upstream providers do not bill for tasks that return FAILED, so a service charging you for one is charging for something it did not pay for. The state to watch is UNKNOWN rather than FAILED — that one falls outside most automatic rules.

What does "The two modes are mutually exclusive" mean?

You sent reference material and a first or last frame in the same request. Wan 3.0 treats those as two different jobs and refuses to combine them. Drop one side: keyframes for a fixed opening, references for a fixed cast.

Why is my Wan 3.0 task stuck at pending forever?

Almost always a front-end mapping UNKNOWN onto PENDING. A task_id expires after 24 hours, and a query after that returns UNKNOWN, which some clients treat as "still working." Nothing is still working.

My video link stopped working. Can I get the file back?

Not from the generation URL — a Wan 3.0 output link is valid for 24 hours only, by design. This is why any service you use should be copying outputs to its own storage the moment a job completes, and why a downloaded local copy is worth the ten seconds.

How many Wan 3.0 jobs can I run at once?

Two concurrently, with up to 50 more queued and a submission ceiling of 30 per minute. Requesting four variants runs two and queues two. Those are model-side limits, not policy, and they apply to everyone calling the same API.

Is a wrong-but-finished generation refundable anywhere?

No, and it would be strange if it were — the model did the work you asked for. Manage it with resolution instead of refunds: draft at 480P where an attempt costs a quarter of the 1080P price, then run the winner once at full quality. Pricing has the numbers.