The problem

Choosing a generative model is usually done on one of two numbers, and both are wrong. Price per image ignores that rejected images cost the same as accepted ones. Benchmark quality ignores that you are not buying quality, you are buying assets that survive review.

Tosskeep generates game art through a quality gate, so the denominator was sitting right there: divide total spend by the number of assets that passed. That is the number a studio actually pays.

The finding

The result that changed the decision was asymmetric, and I would not have predicted it. Post-processing lifts a cheap general model enormously and actively damages an expensive purpose-trained one.

90 75 60 45 raw post-processed General model $0.030 / image 85 55 Purpose-trained $0.360 / image 62 76

Quality scores from the bake-off, on a 100-point scale. Prices are per generated image, before any rejection.

Post-processing closed a 28-point gap to two points. On the run that settled it, the cheap path scored 85 at $0.030 per image against 80 at $0.360 for the purpose-trained one: better output, roughly a twelfth of the price.

Measuring raw scores alone would have led straight to buying the expensive model, and applying the post-processing pipeline uniformly would have quietly degraded it. Both mistakes are the default behavior.

The judge has to be judged

Ranking on approval rate only works if the gate approving things is any good, so two pieces sit underneath the metric.

The frontier refuses to pick

The bake-off output is a Pareto frontier: every configuration not beaten on both cost and quality survives, and nothing is crowned. That is deliberate. Where a studio sits between "cheapest acceptable" and "best available" is a decision about their game, not about the data, and a tool that hides that behind a single recommendation is making a business call it is not entitled to make.

What this is not. Cost per approved asset ranks bake-offs. It is not a runtime router: nothing consumes it at generation time, and model choice still comes from a config table that its own header calls interim. Feeding the metric back into selection is the difference between having measured something and having built something, and I have only done the first.

What I would do differently

The architecture from this project became a production art pipeline at work, rebuilt there in two weeks. It went that fast because the expensive questions, which model, how to judge it, what to do on failure, had already been answered here with data.

← All case studies