The awkward case in specification sourcing is not a third party getting it wrong. It is the vendor publishing two documents that disagree, because then "check the official source" stops being an instruction and becomes a question about which official source.
Here are two live examples from Wan 3.0, both current as of 27 August 2026.
Both are Alibaba. Neither is a rumour. They cannot both describe the current state.
What I do with this: take the later-dated statement, and say that I did. "Generally available since 24 August 2026; the English API reference still carried a preview notice when read on 27 August 2026" is longer than picking one, and it is the only version that survives a reader checking either document. Whichever one you quote silently, half your readers will find the other one and conclude you did not check.
The general rule this is an instance of: when a vendor contradicts itself, publish the contradiction, not the resolution. You are not better placed than the vendor to decide which of its own documents is right; you are only better placed to notice that they differ.
enable_thinking is a boolean in parameters, defaulting to false. It is the switch
that determines whether the model actually reads an attached document or web page.
The sourcing on it is genuinely uneven, and it is worth laying out in full because the evidence tiers matter:
| Source | What it says |
|---|---|
| Alibaba's Model Studio console curl example | Includes "enable_thinking": false in the parameters object |
| Alibaba's English API reference parameter table | No entry. A full-text search for "thinking" returns zero hits |
| fal.ai (gateway) | "Requires enable_thinking=true" for file and link inputs |
| Picsart API platform (gateway) | "Required to process file/link inputs"; media.type file/link "only when enable_thinking is true" |
| Two further gateways | Same |
So: the parameter is unambiguously real — it appears in Alibaba's own request example. What is documented only by third parties is the consequence of leaving it off.
That distinction matters, because the reported consequence is unusually bad. If you attach a document or a link and do not set the flag, the request succeeds, bills normally, and the model does not read the file. No error. You get a video that has nothing to do with your input and no indication of why.
What I do with this: state the tier explicitly in the sentence. Something like — documented by four independent API gateways and present in Alibaba's own request examples, though absent from the English API reference as of 27 August 2026. It reads worse than an assertion. It is the only honest version, and it tells the reader precisely how much weight to put on it.
And separately from the writing question, the engineering answer is not symmetrical. Setting the flag when it turns out to be unnecessary costs some latency. Not setting it when it turns out to be necessary costs a silently wrong, fully billed generation. So the right implementation is to force it on whenever a file or link is attached and not expose it as an option — which is a decision you can make correctly even while the documentation is unresolved.
Neither case is carelessness. They are the normal failure modes of documentation at release velocity:
Different documents have different release trains. A launch announcement ships the day of the launch. A reference page is regenerated when the API surface changes. A console example is edited by whoever last touched the console. The three drift, and nothing in the publishing process reconciles them.
Reference pages describe the stable surface; examples describe what works today. A parameter can be live, functional and load-bearing while its reference entry is still in review. The example is ahead of the table, not wrong.
Translated documentation lags. Where a vendor publishes in two languages, one is downstream, and "the English page does not mention it" is frequently a statement about the translation queue rather than about the API.
Date every specification claim, and name which document it came from.
Not "according to Alibaba" — which of Alibaba's documents, and on what date. That single habit makes both of the contradictions above harmless: a reader who finds the other document sees immediately that you read a different one on a specific day, rather than concluding you got it wrong.
It also makes your own corrections cheap. A dated claim can be re-checked mechanically. An undated one has to be re-researched from scratch, which in practice means it never gets re-checked at all.
That is the format I keep the full parameter table in — every row carrying the source it came from and the date it was read, including the rows that are unflattering — at wan-3.run/wan-3-0-specs. The next note traces a widely repeated figure back to the product it actually belongs to, which is the same method run backwards.