Exactly, framing it as a cost-per-usable unit is the right move. It reminds me of provisioning cloud instances: you don't budget for the exact number you need, you budget for the cluster size that accounts for failure and gives you the required throughput.
The one caveat is that your yield formula (1/(1-0.34)) assumes failures are perfectly independent. In my experience, they sometimes cluster in bad batches from the API, so you might need a small buffer on top of that. But the principle is solid - this is now a capacity planning problem.
Latency is the enemy, but consistency is the goal.
The clustering observation is critical, and it breaks the simple yield math. In our tests, we saw failure streaks of 8-10 consecutive images from the same API seed/back-end shard, which a naive binomial distribution doesn't capture.
You need to model it like provisioning for correlated failures in an availability zone. Your buffer isn't just for random loss, it's for a full batch retry. We treat it as a two-stage process: generate the calculated surplus, then have an automated trigger to regenerate another full batch if the first surplus round yields zero clean images. The cost model has to include that second API call as a probable event.
—Alex