Budgeting a video model: the numbers that actually appear on the invoice

Most comparisons of AI video generators rank the output. That is the wrong first
question for anyone who has to sign off on the bill, because the output quality
gap between the current generation is narrow and the billing structures are not.
A model that charges per generated second behaves very differently in a monthly
budget than one that charges per clip, and the difference shows up long before
anyone argues about which render looks better.

Per second, per clip, or per seat

Three billing shapes are in circulation right now, and they reward completely
different workflows.

Per generated second. You pay for duration, so a twenty-second clip costs
roughly twice a ten-second one. Iteration is the expensive part: five attempts at
eight seconds costs the same as one forty-second final. Teams on this model learn
to storyboard before they render.

Per clip or per prompt. A fixed charge regardless of length, usually with a
hard cap on duration. Cheap to iterate, expensive to produce anything long,
because length is not something you can buy — it is a ceiling.

Per seat, with a generation quota. Predictable monthly cost, unpredictable
capacity. Fine until a deadline week, when the quota turns into the constraint
nobody planned for.

The practical consequence: the model you should pick depends on whether your
bottleneck is iteration count or finished duration. That is a question about your
process, not about the model.

Self-hosting changes the arithmetic, and the risk

Several current video models publish weights for self-hosting, often under a
community licence with a revenue threshold. Below the threshold there is no
per-generation charge; above it, a commercial licence applies. This turns a
variable cost into a fixed one — you pay for GPUs whether you render or not —
and it moves the risk from the invoice to the infrastructure.

It is worth doing the crossover calculation honestly. Take your real monthly
render volume in seconds, multiply by the hosted per-second rate, and compare
against what the equivalent GPU hours cost you including idle time. For low,
bursty volumes the hosted API usually wins. The break-even arrives sooner than
most teams expect once rendering becomes a daily habit rather than an experiment.

Read the duration ceiling before the price

The specification that quietly decides most of this is maximum clip length, and
it varies between tiers of the same product — a "fast" tier sometimes allows
longer clips than the "pro" tier above it, because the constraint is compute per
second, not quality. FuturPulse worked through the current rates and limits in
a per-second comparison of LTX-2.5 against the alternatives,
including which tier actually permits twenty-second output.

Check the ceiling first. If it is below what you need to deliver, the price is
irrelevant — you are going to be stitching clips, and stitching costs editing
time that no pricing page lists.

A short checklist before you commit

• What is your monthly render volume, in seconds, measured rather than guessed?
• What is the maximum single-clip duration you need to deliver?
• How many attempts does a usable clip take in practice, on your prompts?
• Does the licence threshold apply to your revenue, and what happens when you cross it?
• Can you export and re-render elsewhere if the price changes?

FuturPulse covers AI tooling with that kind of separation in mind: what a vendor
publishes as a rate, and what it costs once a real workflow runs through it.
Ongoing coverage is at FuturPulse.