A friend wrote to me on WhatsApp after reading my post on what image and video generation costs. He found it interesting, then asked the awkward question: you measure the execution, not whether the result matches what you wanted. Who pays for the number of executions, the famous loop? If your workflow makes five generations to hand back one, the user asked for a single execution. So what's the cost with a workflow, the cost without one, and what does the application add?
He's right. In my table, the "Succeeded" column meant "the file came out", not "it's what I wanted". Here is my answer, with what I actually measured and what I didn't.
Two prices people mix up
The first price is that of an execution: what the API bills, or the GPU's time multiplied by its rate. That's the price in my previous post, and it's easy to read on an invoice.
The second is the price of an accepted result: an image or a clip the person looks at and says "yes, that's it". If one output in N fits, you make N on average to keep one. And every output has to be looked at, by a model, by rules or by a human.
cost of an accepted result = (cost of one run + cost of checking it) ÷ p
average number of attempts = 1 ÷ p (p: the share of outputs that fit)I pick the p values below to show the formula; I didn't measure them. With the prices from my post: a hosted Stable Diffusion 3.5 Large image costs $0.08 and takes 8 seconds. If one image in three fits, the good one costs $0.24 and 24 seconds of machine time, not counting the person's three glances. A hosted Wan 2.2 A14B clip costs $0.60 and 131 seconds. If one clip in four fits, you're at $2.40 and about 9 minutes of waiting.
The dollars are small. What weighs is attention: four clips watched one by one is four times "I describe, I wait, I judge". No API invoice shows that part.
The loop, and what it changes
A workflow does what the person would do in its place: generate, compare with the intent, try again if it's off, stop when it's right or when the budget runs out.
The loop costs more per request. It can cost less per good result, on one condition: the check must be much cheaper than what it avoids. The best place to check is before the expensive step: a quick preview before the full clip, a still before the video.
An example with prices I measured. On a rented H100, a Wan 2.2 I2V A14B clip takes 18 minutes and costs $1.20. A preview with LTX-Video takes 14 seconds, 1 to 2 cents of compute time. For the example, I assume one start in four gives the right motion.
| Without a workflow | With a workflow | |
|---|---|---|
| Full clips ($1.20, 18 min) | 4 | 1 |
| Quick previews (≈ $0.02, 14 s) | 0 | 4 |
| Who judges | the person, four times, after 18 minutes each | a model or rules on the previews, the person on the result |
| Compute | $4.80 | $1.28 |
| The person's wait | about 72 min | about 19 min |
What the application adds here is the four previews: $0.08, about 6% of the total, plus the cost of the judge, which I haven't measured. The table looks good because I assume the preview predicts the final clip, and that isn't always true. In my bake-off, LTX-Video obeyed a dolly-in that Wan nearly ignored. A preview can approve a shot the final model won't film. So the final result has to be looked at too.
The later you catch the error, the more it costs
I have a real case for this. To test a production chain, I made a 40-second demonstration short film, 10 shots, with Orazaka, my AI engine. The film's production file gives the time of each step. At the H100's $3.99 an hour, that comes to roughly:
An error found on the key image costs one cent. Found in the shot, 36 cents. Found in the cut, 157 times the image. So the loop should check early, not only at the end.
On this film, 12 shots were filmed for 10 kept. At $0.36 a shot, that's $0.44 per kept shot, 1.2 times the price of one run: exactly 1 ÷ p, with p = 10 out of 12. For the film's 35 runs, 5 of them failed, the GPU compute comes to about $7.89. I can't give you a cost per film: the pod's bill, $23.62, mixes several jobs, and I won't pin it on a single film to get a clean number.
Two times I had no loop
The first is the first batch of clips for Orazaka's showcase. I had given Wan a portrait image cropped to 16:9, and a prompt that described a looping movement. The clips were bad. Each clip costs about $1.20 and 18 minutes of H100, so the five I have to redo represent roughly $6 and an hour and a half of GPU that produced nothing publishable. The fix fits in two lines: images made at the video's own proportions, and a prompt that only describes the motion.
Nobody looked at the image before 18 minutes of GPU were launched. Since then, the generation engine writes imageKept in its metrics: the share of the starting image the frame kept (a portrait cut to 16:9 keeps a third). It doesn't say whether the result is good, only that it starts with a handicap, but it warns before you pay.
The second is the birds. For the tour film, every key image is compared with the bird's drawing made in code. Some images were rejected: a duplicated falcon, owl and duck, an audience of humans, a phantom extra bird. The vertical key image of the finale was rejected three times. I didn't insist: the vertical version shows the horizontal shot over its own blurred background. That's my loop's retry cap, held by hand. But I didn't keep the count of rejected takes nor this film's GPU spend, so I can't give you a cost per kept shot, and that's the lesson of this post.
Who pays for the loop?
There are three ways to split the risk.
Charging per execution: the user carries the risk, every retry is paid. It's simple and honest about the arithmetic, but the user pays for the model's misses.
Charging per accepted result: the platform carries the risk and prices it in. For the user it's the most readable. For the platform it's a bet on its acceptance rate, and it needs a definition of "accepted" that can't be gamed.
A hybrid with a cap: the platform absorbs internal retries up to a set number, then hands control back, or bills what follows. That seems the fairest to me, as long as it's transparent: show the attempts, refund the failures, leave a budget cap.
In Orazaka, a credit is reserved before the run, and if it fails the reservation is released: a failed run isn't billed. What I don't have is a judge that retries by itself on quality. Today the judge is me, in front of a grid of frames, and I haven't measured how many retries an ordinary user would make.
How to measure "it's what I wanted"
Four measures, from the simplest to the finest. The acceptance rate: outputs kept divided by outputs generated. A judge score: a vision model reads the image and the brief and grades the gap (what people call "LLM-as-judge"). It has to be calibrated on a sample a human looked at, because a judge is lenient with itself. "Kept" signals: downloaded, published, reused unedited. That's a weak signal; people keep what's acceptable, not always what's good. And the time to the first good result, the one the person actually feels.
In every case, the human in the loop stays the last judge. Models are there to spare them the obvious glances, not to decide in their place.
What I measure, and what I don't
Today I measure, per run: the time, the compute cost, the failures, and imageKept for clips made from an image. Those are execution measures, the ones my friend reproached me for looking at alone.
I don't measure an acceptance rate in the product, nor an automatic judge, nor the person's time. The verdicts on my showcase are mine, by eye. And my p values above are examples, except the 10 out of 12 of the film.
If I had to keep one thing: don't ask what an execution costs, ask what a result you'd actually want costs. Every figure holds for this setup, on 17 October 2026.
