What a per-second rate does and does not include, and which product you are actually calling.
Open-weight video systems ship separate checkpoints for frame inputs and reference inputs. Which one answers your call, and what happens when you pick wrong.
A thing that trips up everyone who moves from a hosted video interface to the raw weights: the product you were using is often not one checkpoint. It is two, sitting behind a router that picked one for you based on what you dragged into the box.
You never noticed because the interface hid it. Then you download the weights, load the one whose name you recognise, hand it nine reference images, and it ignores eight of them.
The common division is between a first/last-frame checkpoint and a general reference checkpoint.
The first/last-frame variant accepts zero, one, or two images. Zero images is pure text-to-video. One image is either a starting frame or an ending frame, and the model interpolates forward or backward from it. Two images pins both ends and generates the motion between them. That is the entire input space. It is small on purpose, and the smallness is why it is good at what it does — the conditioning signal is unambiguous, so the model can commit hard to it.
The general reference variant accepts a mixed bag: multiple stills, several source video segments, several audio segments, all at once, with per-type caps and a total-file cap on top. On the family I have been working with, that is up to nine images, up to three video clips totalling no more than fifteen seconds, up to three audio segments on the same total budget, and no more than twelve files across all types.
Those caps are not arbitrary and they are not a licensing gate. They are the conditioning budget. Every reference you attach competes for the same attention capacity, and the twelfth file is not free — it dilutes the eleven before it.
People treat the reference slots as a mood board. Nine images of "the vibe": a colour palette, two lighting references, a lens look, three faces that are almost the character, an architectural plate.
That is the wrong use. It is a casting call, not a mood board — each slot should answer a question the model would otherwise have to guess, and guessing wrong on. A face it must hold across the cut. A garment whose logo has to stay legible. A room whose geometry has to match the previous shot. If a reference is not preventing a specific, nameable failure, it is spending budget to add noise.
The test I use: for each attached file, write the one-sentence failure it prevents. If you cannot write the sentence, drop the file. Six sharp references beat twelve fuzzy ones, consistently, and the run is cheaper because most providers bill input footage by the second.
Even if you never touch the weights and only ever use a hosted interface, the split is worth knowing, because it tells you which prompt strategies transfer.
Anything you learn about first-and-last-frame control — how to pick a strong end frame, how to avoid the mushy middle on long interpolations, how to use a last frame to force a specific resolution to the action — is knowledge about the FL checkpoint. It does not transfer to the reference path, which is solving a different problem: identity preservation across a generated sequence, not motion between two known states.
And the reverse. Everything you learn about reference weighting, about how many faces the model can hold, about which reference types dominate when they conflict — that is reference-checkpoint knowledge, and pushing it onto a first/last-frame job produces confused prompts and worse output.
Treat them as two tools. Ask which one a given shot needs before you write anything.
Before every generated shot, one question: is this shot defined by its endpoints, or by its contents?
Endpoints means you know where it starts and where it ends and the interesting part is the transit. A logo assembling. A door opening onto a reveal. A character turning toward camera. Use the first/last-frame path, spend your effort on choosing two strong frames, and keep the prompt short — the images are already carrying most of the signal.
Contents means the shot is defined by who and what is in it and must match something that already exists. A recurring character. A product that has to be the actual product. A location established in a previous shot. Use the reference path, spend your effort on choosing the minimum set of files that pin the identity, and write a longer prompt, because the references constrain appearance but not action.
Shots that are genuinely both are rarer than people assume, and when you hit one, the usual answer is to split it into two shots and cut.
The full input limits for the reference path — the nine, the three, the three, and the twelve-file ceiling over all of them — are worth having in front of you when you plan, because they turn "attach some references" into a budget with a hard edge — the reference path written out with its caps is the version I keep open while planning.
None of this is exotic. It is the same discipline as knowing whether you are shooting plates or coverage. The only new part is that the constraint is a file count instead of a call sheet, and that nobody puts it in the UI.
If you want to see which checkpoint answers a given request without reading a specification first, minimax-h3ai.video routes on the inputs you attach and names the path it took, which is a faster way to build the mental model than the docs are.