Cost per AI ad is a denominator problem
Some links on this site are affiliate links. If you sign up through them we may earn a commission at no extra cost to you.
We generate shots in pools by type, a hundred of one slot type and a hundred of another, then fill a template to make finished items. The generation cost is knowable: ¥400 (about $60) for 200 shots. What each finished ad costs is that figure divided by how many you decide to build. At 400 finished items it comes to about ¥1 each, and the two slot types alone allow 10,000 pairings. So the cost per AI ad depends on a number you pick: how many ads you build from one batch.
We also cannot give you a reconciled ledger for our own batch. That is a separate matter, and this article keeps the two apart. The argument above holds regardless of what our records show, because it rests on the pairing count and the shape of the cost rather than on a per-item log. The missing ledger is an admission about how this particular work was run, and it is not evidence for the argument.
(Throughout, “creative” means the ad asset itself. “Shot” means one generated video segment. Currency is ¥ with USD at ¥6.72, 14 September 2026.)
How the pipeline is built
We do not generate an ad from start to finish. We fill a template, and a template is a row of slots.
A typical template is four slots wide: an A-shot, a screen recording, a B-shot, and an end card. Each slot has a type, and we generate shots in pools by type rather than per ad. A batch might be a hundred A-type shots and a hundred B-type shots.
Assembly runs through a tool we built, Xuanyuan Toolbox. It builds the tagged segments into finished items according to the template. Segments carry their origin, so some slots in one finished item can be human-made and others generated. That distinction has to survive assembly, because it is what lets us compare production methods later.
Output is therefore combinatorial rather than linear. Any A can pair with any B, so how many finished items you can build is a decision rather than a consequence.
The arithmetic
Here is one batch, as we accounted for it at the time:
| Item | Value |
|---|---|
| Shots generated | 200 (100 A-type, 100 B-type) |
| Seconds generated | 2,000 (10 seconds each) |
| Rate | ¥0.2 / second (≈ $0.030) |
| Generation cost | ¥400 (≈ $60) |
| Finished items built | ~400 |
| Passing review | ~95% → ~380 |
| Generation cost per approved item | ≈ ¥1.05 (≈ $0.16) |
| Human production, per item | ¥15–20 (≈ $2.20–3.00) |
| Ratio | roughly 1/14 to 1/19 |
The reuse count carries the whole mechanism, so it is worth checking. Each finished item consumes one A-shot and one B-shot:
| Shots generated | 200 |
| Shot-uses consumed | 400 items × 2 shots = 800 |
| Uses per generated shot | 4.0 |
| Cost per item if every shot were used once | 2 × ¥2 = ¥4 |
| Cost per item at four uses | ≈ ¥1 |
The batch implies four uses per shot. We did not set that as a target.
The obvious next claim is that AI reuses and human production does not. That claim would be false. Editors reuse footage, templates and packaging constantly. Our own pipeline mixes human-made and generated segments inside the same finished item, which is why the origin tagging in Xuanyuan Toolbox exists at all. Both kinds of segment are present, and the assembly step has to be able to tell them apart.
The real difference is narrower and more useful: which cost recurs. When a shot is cut by hand, the footage may be reused, but the editor’s time is spent again for every new item. Here the generation cost is paid once for the pool, and assembly is automated. Assembly is not free at this scale even when the tooling is automated, and what still recurs is review. The ¥1.05 above is therefore a generation line, not a production cost. What the ¥1.05 does not include is the review that produces the 95% figure, and review is the labour we most want to price.
Two separate claims
Running these two together is what makes this genre slippery.
What is conceptually true
Cost per item is what it cost to generate the shots, divided by a number someone chooses. If we had built 4,000 items from the same ¥400, the figure would have been about ¥0.10. If demand had been 100, it would have been about ¥4. None of those numbers is wrong, and none of them is the cost.
The pool is the part that is knowable: the cost of generating a set of shots. It is fixed and checkable, and it does not move with how many items you assemble from it. A per-item figure without its denominator is not a measurement, because the denominator is a choice rather than an observation.
What is an admission about us
Several people ran this method across the period, none of them kept a per-item log, and the tooling was built to assemble items rather than to count them. That is why we cannot reconcile the figures above against a record.
The two slot types allow 10,000 pairings. We built about 400 items from that batch, which is 4% of the space, because 400 was what the account demanded, and nobody recorded the count as it went.
That is a process failure, and it is ours. Had we run the same batch with the accounting we keep now, the per-item figure would be a recorded number rather than a recalled one.
The missing ledger does not support the argument above, and the argument does not need it. The gap is one we should have closed.
Why the price per second is the wrong number too
Most published figures about AI video are per-second prices, and readers reasonably assume the cheap model is where the savings come from. In our case that assumption is backwards.
The model in this dataset cost ¥0.2 per generated second. The model we run now, MiniMax H3, costs ¥0.09 per second at 768P. The old model was more than twice as expensive per second, and it still produced finished items at about ¥1 each.
The savings came from generating shots as reusable pools rather than as components of a single ad. A cheaper per-second rate applied to a single-use pipeline would not have produced the same figure.
We did not move to H3 because it was cheaper. We moved because the earlier model’s quality ceiling was the problem, and it happens to be cheaper as well. The model we run now is both better and less expensive per second than the one that produced ¥1 items. A per-second rate therefore carries almost no information about cost per finished item. The connection runs through the number you divide by, not through the price list.
The rate itself is also less fixed than it looks. The same model cost ¥0.11 per second on one channel and ¥0.83 on another, for identical output, so a quoted price per second has to name the channel before it means anything.
What actually moved conversion: the template
The pipeline was built to make creative cheap and therefore testable, and that part of the plan worked. We did not design for where the real lever turned out to sit.
The template. Polishing the template moved conversion more than producing more items did. Three things we found by iterating, and none of them was in the original design:
- Slot count. We cut at four segments, then at five. The extra segment changed how the item paced.
- The pre-roll. What happens before the first slot.
- On-beat cutting. Where the cuts land relative to the audio.
This is production experience, not a controlled test. We did not run template A against template B in a matched campaign, and we cannot tell you how much of the improvement is the template versus the account, the season, or the offers. It is the reason we changed direction rather than a demonstrated effect size.
Why we changed route
Put those two findings together and the strategic conclusion follows.
We built a cost-first pipeline: segmentation, assembly, reuse, and volume. It was cheap enough to test at a scale that manual production could not reach. Its weakness was not the cost. The quality ceiling showed up downstream instead: the items were a little worse than what a person would have cut, and in our own delivery data the users they acquired behaved a little worse as well.
So we moved to a quality-first route on MiniMax H3: match human video quality first, then look at the cost. That reverses the order of the original design.
The reason is the template finding. If the lever that moves conversion is structure and craft, then a pipeline optimised for volume is optimising the wrong variable, and a large part of the theoretically available savings is not collectable. The cost advantage was real and it was not the binding constraint, because the lever that moved conversion was structure rather than volume.
What this does not say
It does not generalise. This is one pipeline, in one team, over one period, for direct-response advertising. The mechanism transfers to anyone arranging work the same way, and the numbers are ours alone.
It is not a verdict on a model, or on our own workflow. The generator here was an earlier, lower-end model, and the template findings arrived late, by iteration rather than by design. The model and the way work is split between it and the people around it both have obvious room to improve. That is why we changed route, and it is what we are working on now.
It is not a claim about brand advertising. Everything here is direct-response work measured on conversion events, where the brief is product-driven. Results from brand creative are a different category, and they do not transfer in either direction.
Method
- Pipeline: template with typed slots, shots generated in pools by type, and assembly with human/AI segment tagging in Xuanyuan Toolbox, our own tool.
- Source of figures: production accounting from the period as recalled by the team. Not a per-item ledger. See the section above for why no ledger exists.
- Model rate: ¥0.2 per generated second for the batch described, and MiniMax H3 at ¥0.09 per second (768P) is what we run now.
- Review rate: ~95% approved, as recalled. Review labour is not included in the per-item generation figure.
- Template findings: production experience, not a controlled test.
- Currency: ¥ with USD converted at ¥6.72, 14 September 2026.
What we are working on next
A controlled template test. The template claim is the one that changed our strategy, and it is the one we have not measured. Two templates, matched campaign, matched budget rule, one variable changed. That converts production experience into evidence, and it is the highest-value measurement available to us right now.
Costing the review line. The 95% approval rate implies a review step that the per-item figure excludes. If review costs a meaningful fraction of the pool, the comparison against human production narrows, and we would rather know by how much than assume.
What the quality-first route actually costs. The whole point of moving to a higher-quality model was to lift the ceiling. Whether it does, at what cost per finished item, and whether the pool logic still holds when each shot is generated for a specific ad rather than a reusable pool: those are open questions, and the second one matters most.
To come back to where we started: what it costs to generate a batch is a fixed, checkable number, and everything after that depends on how many ads you build from the batch. No single figure for the cost of an AI ad can be right on its own.