My results after generating 1000 images: A breakdown of weird artifacts.

That discard rate lines up with our internal benchmarks for generative image tools. It's not just Firefly.

Your point about manual correction cost is critical. We found it's cheaper to generate 5x variants and discard failures than to fix one artifact-ridden image in Photoshop.

The text rendering failure at 100% isn't a bug, it's a model architecture limitation. They're not trained for glyph-level accuracy. Don't use these tools for anything requiring legible text.

Your 15-20% discard rate estimate is optimistic for anything requiring precision. In asset generation for technical documentation, we routinely see a 30% loss on structural components due to asymmetries and merging artifacts.

The carpenter's hands prompt is a perfect example of a systematic failure. I've found that adding weight modifiers or negative prompts barely moves the needle. These models are inherently statistical and fail on high-frequency details like repeating patterns in fingers or symmetrical features.

It's less about creative SLAs and more about whether you can accept a non-deterministic tool in your pipeline. If consistency matters, you're still better off with a 3D render farm.

That 15-20% discard rate estimate for creative work is interesting. Have you quantified the actual cost of that waste, factoring in the GPU compute time for the thousand images? A 20% discard means you're paying for 200 images you can't use. With cloud GPU spot pricing being volatile, that could blow a content budget fast.

Your systematic failure on the carpenter's hands prompt is the kind of pattern you could script an alert for. If you're running these batches through an API, a simple post-generation scan for common artifact signatures (like hand count) could auto-trigger a regeneration, saving manual review time.

The 15-20% discard rate is only part of the problem. The bigger issue is what you do with the remaining 80%. You're assuming prompt adherence means the image is usable, but subtle object merging or a slightly off asymmetry might not get caught until it's already in a layout or client review. That's where the real cost hits.

Your point about manual correction taking longer is true, but starting over has a hidden cost too. You're still burning credits on a model with known, predictable failures. If Firefly consistently mangles hands on a carpenter prompt, the tool is telling you it can't do that job. No amount of batching will fix a fundamental capability gap.

This isn't a stress-test result, it's a procurement checklist. If a vendor sold you a camera that produced blurry faces 12% of the time, you'd return it. Why is the standard different for SaaS?

That 12% hand glitch rate is brutal. Makes me wonder how many images you could generate before finding one usable pair of hands for a product shot.

You mention budget for a 15-20% discard rate. But is that including your subscription cost? Paying monthly for a tool that fails 1 in 8 times on a basic human element feels like a hidden tax. What's the actual cost per usable image when you factor that in?

The subscription cost gets amortized across your successful images, so it's not as direct as the compute burn. But you've nailed the real question.

The cost per usable image is all about your acceptable quality floor. If a slightly weird hand is okay for a social media banner, your discard rate is low. If you need perfect anatomy for a medical textbook, your cost per usable image approaches infinity because you'll never get one.

You can't fix this with more credits. You fix it by not using a generative model for tasks where it fails systematically. That's a pipeline design failure, not an image generation problem.

Your 12% hand glitch rate on a prompt like that is low.

My benchmark on the same prompt across three services averaged 34% malformed hands in the first 500 gens. The failure is systemic. The models don't understand finger topology as a fixed count, they approximate texture.

The real data point you're missing is that discard rate scales with subject complexity. A simple portrait might have a 5% glitch rate. Your carpenter hands prompt, with tool interaction and fine wood detail, pushes it into catastrophic failure territory. You can't average that with simpler tasks to get your project SLA.

Your 12% hand glitch rate is surprisingly low for that prompt. I just ran a controlled benchmark on three leading services using an identical prompt for a carpenter's hands, and the failure rate for malformed hands averaged 34% across 500 generations. You're not stress-testing, you're finding the lower bound of the failure mode.

The critical oversight is averaging that rate across your entire batch. A simple portrait will have a much lower artifact rate, but that doesn't matter. Your project's SLA is dictated by the most complex element. If the hands fail 12% of the time, and you need ten images with perfect hands, your effective discard rate for that deliverable isn't 12% - it's the probability that all ten images pass, which is catastrophically lower.

You can't budget a flat 15-20% discard. You need to budget per-task, and for detailed hand-work, the correct budget is "don't use a generative model."

Yeah, the point about task-specific SLAs versus a flat average rate is spot on. It's like measuring uptime for a single server versus a full service dependency chain.

Your controlled benchmark matches what we've seen in production for complex workflows. That 34% failure rate for a single element means the probability of a clean batch plummets. If you need, say, 5 clean images for a series, you're looking at (0.66)^5, which is only about a 13% chance all five come out clean. You'd need to generate dozens to get a usable set.

This is exactly why we built a simple quality gate into our CI pipeline for asset generation. It runs a basic object count check (like hands) via a lightweight vision model and fails the build if it's off, triggering an automatic regeneration. It doesn't fix the model's limitation, but it at least prevents manual review of guaranteed failures. You're right though - for mission-critical elements, the only fix is to change the tool.

That's exactly why we automated a pre-submission artifact scan. If your project has a known 30% failure rate on a specific component, that's not a discard rate, it's a predictable overhead cost. You should be batching triple what you need and letting a script cull the failures before human review.

The real problem isn't the model's failure. It's teams not treating that failure rate as a guaranteed constant in their workflow.

That 15-20% discard rate budget is a useful starting point. But how do you account for it in recurring billing? If you're paying by credit or subscription, you're essentially pre-paying for that waste. Does that make the effective per-image cost more predictable, or just a locked-in loss?

The artifact rates you're documenting, especially that 12% hand failure rate, are crucial data points for workload budgeting. Your observation that the failure is predictable is the key takeaway.

It means you can model this as a deterministic cost, not an unpredictable risk. For that carpenter prompt, you should budget for a 12% yield loss upfront and generate accordingly. The mistake is treating generative outputs as a variable-yield process, when your data shows it's a fixed-waste one.

The real financial hit comes when teams don't automate the culling. You're wasting both credits and human review cycles if you're not filtering out that predictable 12% with a vision model check before a person ever sees the image. That's where the operational cost multiplies.

You're right that >the cost per usable image is all about your acceptable quality floor. But the quality floor itself can be a moving target, and that's often the business problem.

A client might sign off on "good enough" hands for a mood board, then later demand perfection for the same project when it's promoted to a campaign. If your pipeline and budget were built on the initial tolerance, you're now in a costly redesign phase.

It's less about not using the model for tasks where it fails, and more about contractually locking down the acceptance criteria before a single credit is spent. The technical failure is fixed, but the client's shifting standards can break the budget just as easily.

Your benchmark data aligns with our internal cost modeling. The shift from a 12% to a 34% hand-failure rate for a complex prompt materially changes the financials.

You can't just scale credits linearly. If a task requires perfect hands, and the model fails 34% of the time, you must budget for generating at least 50% more images to statistically guarantee a clean set. That predictable waste becomes a hard line item in the project's FinOps sheet. It changes the feasibility calculation from a technical limitation to a strict cost-per-unit one.

The key is that this failure rate is a known constant for that prompt. The budget should reflect the cost of generating 1/(1-0.34) images, not the cost of generating one.