The catalog audio boolean is not a capability flag
It is true on some plain text-to-video rows with no audio features; /best only trusts named audio tags or text-to-audio.
It is true on some plain text-to-video rows with no audio features; /best only trusts named audio tags or text-to-audio.
Every catalog record can carry audio: true | false | null. That field is a leftover boolean, not a capability. It is true on several plain text-to-video models whose feature list never mentions audio — no native audio, no audio sync, no driving audio, no audio input. Best model with native audio deliberately ignores it. The ranking filter is named tags and the text-to-audio category. If you sort the catalog on the boolean, you will rank rows that cannot (or do not claim to) make sound next to rows that can.
The boolean is a field, not a filter
The comment in the ranking code names the failure: audio is true on models such as Seedance V1.5 Pro text-to-video with zero audio-related features or categories, so it does not reliably signal audio capability. Only explicit, named audio feature tags and the text-to-audio category are trustworthy enough to claim "has audio."
That is a methodology fact, not a taste ranking. /best is a filter plus a sort over the published model set. Same models.json in, same table out. The audio page's criterion is: models with an audio-related category or feature tag, sorted by best leaderboard position (unranked after, cheapest complete job first), capped at 25. The spec column prints the matching tags — "native audio," "audio sync," "driving audio" — or "Text-to-audio" when the row is an audio content type.
A spreadsheet of audio === true is a different, worse list. It will include Pixverse 5.6 text-to-video, WAN V2.6 text-to-video, LTXV2: published T2V rows whose features are prompt-based video, not sound. It will also include rows that do make sound but never wrote the word "audio" into features. The boolean is noisy in both directions. The ranking page picked the direction it can defend: require a named tag.
What /best actually reads
hasAudioSignal is three checks:
content_type === "audio", orcategoriesincludestext-to-audio, or- some feature string matches
/audio/i
That is it. Description text is not scanned. The raw boolean is not read. A marketing sentence that says "native audio" in description does not get you on the page if the tags stay "Cinematic, Premium." A feature named audio_sync does.
Rows that belong there look like Seedance 2.5 (audio_sync), Happy Horse 1.0 text-to-video (native_audio), WAN 2.7 text-to-video (audio_input), WAN 2.7 image-to-video (driving_audio), Veo 3.1 reference-to-video (Audio), plus the dedicated speech rows (Grok TTS, Cartesia, Inworld, ElevenLabs, MiniMax Speech, Qwen TTS). Those are generate or accept audio as a tagged job. The boolean happening to be true on them is coincidence, not the reason they ranked.
Kling 3 Turbo text-to-video is the other pole: audio is false, features are text_to_video. Do not prompt it as a talking clip and do not expect it on the audio ranking. Silence is the row.
Sound on the bill is a third question
Whether a model can emit audio and whether audio changes the credit formula are different pages. AI video with sound is the meter: native audio as a rate switch (audio-on versus audio-off per second), versus adding a voiceover as its own line. A model can have a named audio tag and still bill like a silent clip. A model can bill an audio toggle and still need the tag to appear on /best. Do not use the cost page as a capability list, and do not use the boolean as a price toggle.
If the job is "I need a clip that talks," open the audio ranking, read the spec column, then pin that slug in the brief. If the job is "I need to know what sound costs," open the cost scenario. If the job is "does this one row have audio: true," you are asking a question the product has already decided not to trust.
Use the ranking, not a dump of booleans
The catalog page will keep showing whatever fields the record has. That does not make every field a buyer filter. Fast, premium, audio — some of those are maintained as flags with a job (speed-optimized variants, top capability tier). Audio-the-boolean is the one /best called out as unsafe. Trust the tags that name the work: native audio generation, driving audio input, audio sync, audio input, or a text-to-audio category.
When a new row ships with audio: true and a feature list that only says "Text-to-video," it will not appear on the audio ranking until someone writes an audio tag. That is the point of the filter. It will disappoint you if you believed the boolean. It will not disappoint you if you believed the tags.
FAQ
Why not just use audio: true?
Because it is set on plain text-to-video rows with no audio features. Ranking those as "best with audio" would be a false capability claim. Named tags are the disclosed methodology.
Does a description that mentions native audio count?
No. The filter does not scan descriptions. It reads content_type, the text-to-audio category, and feature strings that match /audio/i.
Where do speech models sit?
Dedicated text-to-audio and content_type: audio rows qualify even without an "audio" feature string. They are the speech catalog — TTS, clone, design — not a silent T2V with a sticky boolean.
Will pinning a boolean-true T2V give me dialogue?
Only if that row actually generates audio. Many boolean-true T2V rows have no audio tags and no audio job. Pin a model from the audio ranking, or read the tags on the model page, then name that slug in the brief.