Why the terms and the price sit on different pages
Across the pages behind this register, the material describing what a tool can do is consistently more detailed than the material describing what it costs. That gap is not an accident of layout; the two documents are written for different reasons. As of 2026-09-12.
| Kind of page | Usually detailed about | Usually silent about |
|---|---|---|
| Product or capability pages | Features, models, workflow, languages | What any of it costs per unit of output |
| Rate or price pages | A figure, sometimes a tier | Ceilings, throughput, what a failure costs |
| Developer documentation | Limits, parameters, maximum durations | The commercial terms around the limits |
| Plan and billing pages | Monthly figures and allowances | How much output an allowance buys |
Inclusion rule. The four kinds of page a rate and its terms are spread across in this register. A vendor publishing everything in one place would need only one row. Order. In the order a buyer usually finds them.
1A feature is marketing and a rate is a promise
A capability page can describe an ambition and be revised quietly. A published rate is something buyers will hold a company to, and a published limit is something support will be asked about. The incentives on the two documents are not the same, and the detail follows the incentives.
That predicts the pattern this register sees repeatedly: a tool with an excellent description of its workflow and no readable price, or a rate card with four figures and nothing about how long one generation may run.
2Four pages to answer one question
Costing a finished minute can require the rate page for the figure, the developer documentation for the generation ceiling, the plan page for the credit rules, and a capability page to know which model the tier actually uses. None of those pages links to the other three.
Assembling them is most of the work a register does, and it is why every row here carries the address it came from. A figure without its source cannot be reassembled by anyone else.
3What a buyer should ask for in writing
Four sentences settle nearly everything: what a second of output costs at the delivery resolution, how long one generation may run, how many may run at once, and what happens to a generation that fails. Each of those is short, and each is usually on a different page or none.
Where a seller cannot point at all four in public, that is itself a finding rather than a reason to abandon the comparison. It puts a channel in the part of this register about absences, which is a real place with real entries.
Written to explain, not to record. No sentence here is attributed to a seller, and none of it should be quoted as a fact about one. The sourced material is on the ledger. Related: Per-second billing, Budgeting a series.
4What the seconds buy
Price aside, what goes into the seconds behind “Where terms live” is described in SceneMixer's guides:
Typically 60–120 seconds, always 9:16 vertical, ending on a hook. SceneMixer's episode outlines are generated with that pacing, and setting a project to 9:16 makes every segment vertical (the default is 16:9).
SceneMixer, How to Make ReelShort-Style Dramas with AI — “How long is a ReelShort-style episode?” (read 2026-10-13)
Downloads and the asset library follow your Music switch; a shared link always plays the version with the episode’s music.
SceneMixer, Background Music in an AI Short Drama: The Built-in Score — “Does the music carry into downloads, the library and shared links?” (read 2026-10-13)