An ingest path for a video model has four categories of refusal, and they need four different sentences. Most implementations write one.
| Category | What the user did | What they should do next |
|---|---|---|
| Format | Attached something the model does not read | Convert, or pick another file |
| Item limit | One file is too big, too small, too wide | Fix that file |
| Request budget | Each file is legal; together they are not | Remove one thing |
| Combination | Two legal inputs that cannot coexist | Choose a route |
The last two are where the generic message does real damage, because in both cases every file the user attached is fine, and a message that talks about files sends them to inspect the one thing that is not wrong.
Bad: Reference video is too long.
The user opens their clips. Each is under fifteen seconds. They conclude the tool is broken, because from where they are standing it is.
Better: These 4 clips total 22 seconds. A request allows 15 seconds of reference video in total. Remove about 7 seconds.
Three things happened there: the scope was named, the arithmetic was shown, and the remedy was quantified. The user now removes one clip instead of re-encoding four.
Bad: Invalid parameter combination.
Better: A last frame and a reference set cannot go in the same request. Keep the last frame to pin how the shot ends, or keep the references to hold a face across the take.
The second version does the thing the API's own message does well and interfaces usually strip out: it states what each side is for, so the choice is a creative decision rather than a coin flip. If the user does not know that keyframes and references buy different kinds of consistency, "choose one" is not actionable advice.
Format, dimensions, aspect ratio, page count and byte size are all determinable in the client. There is no reason to spend ninety seconds uploading a file you already know will be refused, and no reason to make the user wait for the network to tell them something arithmetic could have.
The cost of a rejection is almost entirely the delay in front of it. A refusal at 200 ms reads as validation. The same refusal at 90 seconds reads as failure.
The subtlest category is not a refusal at all. Some inputs are silently accepted and altered:
None of these are errors and all three change the result. An interface that reports nothing here is technically accurate and practically misleading. The honest pattern is a quiet line under the result: what ran, at what size, from what text. It costs one row of UI and it removes an entire class of "why does this look different from what I asked for" conversation — the case for printing the model, the size and the upstream job ID under every result is the same argument applied to the output side of the same pipeline.
Every message should end in a verb the user can perform. Convert this file. Remove one clip. Choose a route. Set a resolution. If you cannot write the verb, the message is not finished — you have described a state instead of offering an exit.
Behaviours described on this page were read from Alibaba Cloud Model Studio's Wan 3.0 API reference on 2026-08-25.