The flat rate that wasn’t: $0.134 advertised, $4.75 billed

The plan was ordinary: generate an eight-second shot from a reference image, at native 1080p, on a provider advertising one of the better per-second rates for that model. The published figure was $0.134 per second, flat across text-to-video, image-to-video and reference-to-video. Eight seconds, so a little over a dollar. Fine.

The run billed $4.75. That is $0.594 per second, or 4.4 times the advertised rate.

What “flat” meant

The rate was flat across generation modes — text-to-video, image-to-video, reference-to-video — which is what the sentence actually claimed. It was not flat across resolutions, and native 1080p was not in it at all. The word doing the work was “native”: the cheaper path renders at 720p and upscales, which is priced differently and looks different. On footage with small text or fine borders, the upscaled version smears synthetic type badly enough to be unusable, so the expensive path is not optional.

Nothing here was hidden. The information was on the model page. It simply was not on the page with the number on it, and the number was the thing everyone quotes.

The comparison it broke

The advertised $0.134 made this provider look about 6.7 times cheaper than a competitor publishing $0.90 per second at 1080p. On the measured figure it is about 34% cheaper — still the better deal at that tier, but a completely different decision. A 6.7x gap might justify rebuilding a pipeline around one vendor. A 34% gap needs to be weighed against reliability, output quality and switching cost.

You cannot check this from inside your own script

The part that makes this hard to catch: that provider returns no cost field on its prediction endpoint, and the obvious balance endpoints are not there either. Spend is readable only from the web dashboard. A script cannot verify what it just spent, so any pre-run estimate stays an estimate, and the only reconciliation available is a human opening a billing page after the fact.

That is worth knowing before you build a budget guard on top of a provider: the guard can only ever be as good as the numbers the API gives it back.

What we do now

• Price the tier you will ship. Not the model, not the headline — the exact resolution and mode, because that is where the exclusions live.
• Reconcile one paid run per provider before planning around its rates. One invoice is enough to catch a 4.4x gap.
• Mark every unreconciled figure as published, not measured. Our own notes carry that distinction on every row, and this site does the same.
• Assume the API cannot tell you what it spent until you have seen it do so.

This is also why the price table on this site is labelled a survey of published rates rather than a benchmark. Sixteen rows of vendor pricing are useful for narrowing a shortlist. They are not evidence of what you will be charged.