A question went up on the radar this evening that deserves a straight answer: what does AI video actually cost once you include all the failed generations? The poster’s point is that price per generated second is a useless number, because a clip that comes back with broken movement or a face that changes halfway through still charged you for it.
We published a 16 minute episode this morning, and we have a rule here that we never delete a generation. So the folder is still sitting there with everything in it, and we can just count.
The count
That episode has 44 rendered beats in the finished cut, plus a three shot cold open.
On disk, from making it: 105 video clips out of MiniMax H3. Sixty three beats, sixteen replaced takes in a re-roll folder, twenty six cold open attempts. A bit under half of what we rendered is in the episode.
The GPU time for the beats that shipped was 242.6 minutes. Re-rendering eight chapter openers that were not good enough cost another 63.7 minutes. So about five hours of render for a 16 minute episode, and a fifth of that five hours produced nothing new, it produced second attempts at things we had already made once.
That is one RTX 5090, one episode, and it does not count the still plates, the voice track, or the nine full builds of the timeline before the one we published.
Price per second is not a constant
Here is the part that makes the pricing page misleading even before you count retries.
We measured eight of our own clips, all the same model, same settings, same card, and the cost per second of finished video is not flat. It climbs with the length of the clip:
| clip length | wall clock | multiple of realtime |
|---|---|---|
| 5.2 s | 130 s | 25x |
| 9.4 s | 341 s | 36x |
| 10.8 s | 428 s | 40x |
| 12.3 s | 533 s | 43x |
| 25 s | 2183 s | 87x |
A 25 second take is not five times the price of a 5 second take. It is closer to seventeen times. Anyone quoting a single multiple for a video model is quoting the length they happened to test.
The same relationship shows up in quality. Our six short beats invented no camera cuts at all. The 25 second pass invented one at 22 seconds in, which made it unusable, which means the most expensive clip we rendered was also the one most likely to be thrown away. Short beats are cheaper and they survive more often, so the frugal way to shoot turned out to be the better way to shoot.
Our full day of bench numbers on this model has the rest of it.
The line item nobody prices
The poster asked whether to track cost per attempt, cost per usable clip, or total project spend. Cost per usable clip is the right one of those three. It is still not the whole bill.
On this episode we ran a spot check on every beat at 12 frames, and everything passed. Later we looked again at half a frame per second across the whole clip, and found ten defective beats that the spot check had missed. Cuts to a close up we never asked for. Smoke appearing in a studio. A dissolve into a different room.
Ten bad clips that a reasonable quality check had already cleared. The GPU cost of missing them would have been zero. The cost would have been an episode with ten visible faults in it.
This is why cost per usable clip undercounts. It prices the render, and the render is the cheap input. The expensive input is somebody looking at all of it properly, which is slow, which does not appear on any pricing page, and which is the thing you quietly skip when you are behind.
There is a good example of the same trap on the radar today from the other direction. Somebody built a comparison page for H3 speed up methods, which is a useful piece of work and generous to publish. Quality on it is scored from a handful of extracted still frames, and the author says so plainly in their own post, adding that you would have to judge the audio and the temporal consistency yourself. They are right, and our ten beats are what that caveat looks like in practice. Every fault we missed was a fault in time rather than a fault in a frame. Stills cannot see them.
What we would actually track
Three numbers, and only one of them is money.
Clips rendered against clips shipped. Ours was 105 against about 47. If you know that ratio for your own work, you can multiply any pricing page by it and get something close to the truth. If you do not know it, you are budgeting against the best case.
Rework as a share of first renders. Ours was 26 percent this episode, and it is the number most likely to fall if you get better at prompting, so it is the one that tells you whether you are improving.
Minutes of inspection per minute of output. The uncomfortable one. We have never written it down properly and we should, because it is the only line that catches the failure mode above.
The local footnote
All of the above is in wall clock rather than credits, because we render on a card we own. Five hours of a 5090 at full tilt is well under a dollar of electricity, which makes the cash cost of this episode close to nothing and the real cost a day of the week.
That is a different shape from a credits balance and it changes what you optimise. When retries are billed, you get careful about attempts. When retries cost time on a machine sitting in your room, you get careful about clip length, because a bad 25 second take costs 36 minutes and a bad 10 second take costs seven.
The ratio though is the same wherever you run. You will render roughly twice what you use, the retries are a quarter again on top, and the part that decides whether the project is any good is the part where somebody watches all of it at a speed slow enough to catch what the spot check let through.
A daily note from our news radar. The week gets the full treatment in the DIY AI Brief every Monday.