Input Gate NotesWhat a video model will accept, and why the rejection usually happens before any compute runs.

Validate the request, not the file

This is the bug that ships. It ships because it passes every test you would naturally write.

A user attaches five reference clips. Your uploader checks each one: format accepted, dimensions inside the window, duration under fifteen seconds, size under the cap. All five pass. The request goes out and comes back refused.

The limit was never per file.

Where the totals are

Wan 3.0's reference budgets are expressed as totals across the request, not as allowances per item:

Input	Count	Duration	Size
reference_image	up to 10 images	—	20 MB each
reference_video	up to 5 clips	1–15 s each, 15 s total	100 MB each
reference_audio	up to 5 tracks	1–15 s each, 15 s total	15 MB

Read the middle column twice. Each clip may be up to fifteen seconds, and all of them together may be up to fifteen seconds.

So five three-second clips pass. Two ten-second clips do not — even though ten is a legal per-clip value, and even though two is well under five.

Why per-file validation is the intuitive wrong answer

Because every other limit on the page really is per file. Format is per file. Dimensions are per file. The megabyte cap is per file. The page count on a document is per file, because there is only ever one document.

The durations are the exception, and an exception embedded in a table of non-exceptions is almost invisible. You read the row, you extract "15 s", you attach it to the object you were already validating, and nothing in the reading experience flags that this one number belongs to a different scope.

Three budgets, and they do not pool

The other half of the same mistake is assuming the budgets trade against each other. They do not.

Images, video and audio each have their own count, and an unused image slot buys you nothing in the video budget. Ten images, five clips and five tracks is a legal maximum in one request; it is not "twenty attachments" with a flexible mix.

This matters for interface design more than for the API call. A UI that shows one "attachments" counter is describing a budget the model does not have, and every user of that UI will eventually construct a request that the counter says is fine.

What the validator should actually do

Validate in two passes, and keep them separate in the code:

1. Per item. Format, dimensions, aspect ratio, byte size. Reject early, reject locally, and say which file.
2. Per request. Sum the durations within each media type. Count the items within each media type. Check the family-exclusivity rule. Reject before serialising, and say which budget was exceeded and by how much.

The second pass is the one that does not exist in most implementations, and it is the one that produces the production incident, because it only fails when a real user attaches a realistic set of material rather than the one test file.

The user-facing half

"Reference video too long" is a bad message here, because no reference video is too long. The honest message names the total: these clips add up to 22 seconds; the budget for the whole request is 15. Then the user removes one clip instead of re-encoding all five.

If you are building the front end for this rather than the validator, the question of which reference material is worth spending the budget on is a separate and more interesting problem — how numbered reference inputs are addressed in the prompt covers which slot does what, which is what decides where the fifteen seconds should go.

Reference budgets on this page were read from Alibaba Cloud Model Studio's Wan 3.0 API reference on 2026-08-25.