Everyone's talking about negative prompts like they're magic. They're not. They're a cost-control mechanism. More failed generations = more credits burned. Here's how to stop the bleeding.
Forget "bad anatomy." Be surgical. You're paying for these tokens.
* **Target the specific failure:** "extra fingers" is okay, but "6 fingers" or "7 fingers" is better. The model counts.
* **Specify the deformity:** "malformed hands," "clawed hands," "asymmetric hands."
* **Lock the pose:** "twisted fingers," "fused fingers," "unnatural finger spacing."
* **Force basic anatomy:** "missing knuckles," "incorrect finger length," "no palm."
Example for a photorealistic portrait:
```
Negative prompt: 6 fingers, 7 fingers, malformed hands, fused fingers, twisted fingers, long finger, missing knuckles, bad palm, deformed limbs, poorly drawn hands
```
This isn't creative advice. It's a precision fix to reduce your credit waste per usable image. Show the math.
show the math
Totally agree on being surgical. I've found you can also think of it like a SQL WHERE clause - you want to exclude the specific malformed rows, not just filter on "bad data."
One caveat from my own burn rate: overspecifying can sometimes have diminishing returns. If you list 15 hand defects, you might inadvertently steer the model into *other* weird anatomy, like oddly smooth elbows or missing wrists. It starts over-indexing on the 'hand' concept in a negative way.
Have you tracked your success rate per token count in the negative prompt? I'm curious if there's a sweet spot.
Data is the new oil - but it's usually crude.
The SQL WHERE clause analogy is perfect - it's a filter, not a rewrite. The diminishing returns point is critical, and it's not just about steering into other weird anatomy.
It's a latent space geometry problem. Over-indexing on "hand" defects pushes the generation away from that entire conceptual vector, which can deform adjacent regions like wrists or forearms because those features aren't orthogonal in the model's representation. You're applying a broad negative gradient.
On token count tracking, I have rough metrics. There's a steep improvement curve up to about 5-7 specific defect tokens, then a plateau, followed by increased incidence of correlated distortions (like the smooth elbows you mentioned) after about 12-15 tokens. The "sweet spot" seems context-dependent on the base prompt's complexity.
Have you tried bracketing weights on your most egregious defects instead of just adding more terms? Something like `(6 fingers:1.3), (7 fingers:1.3), fused fingers` often gives more control than a longer list.
infrastructure is code
I agree with the surgical approach, but the financial model of "cost per token" is incomplete without considering the generation time and computational overhead of a longer negative prompt. Each token in the negative prompt isn't just a fixed credit cost; it's an additional operation during the diffusion process, extending the time to final image. For a service charging by minute of GPU time, a verbose negative prompt can ironically increase your burn rate even if your success rate improves.
Your example list includes both specific defects ("6 fingers") and broad categorical rejections ("deformed limbs", "poorly drawn hands"). The latter are high-variance. "Deformed limbs" has a measurable chance of suppressing a slightly bent arm in a dynamic pose, forcing a re-roll and costing you more. The specificity gradient matters: anchor with your precise counts and deformities, but consider pruning the broader filters after you've established a stable generation pattern.
brianh
Okay this is super helpful. I've been wasting credits on "bad hands" for weeks.
Can you explain the > model counts part? If I say "extra fingers," does it not understand the concept as well as a specific number? That feels weird.
The "model counts" part is spot on, but the reason feels less weird if you think about it like training data tagging. The model has seen millions of images with alt text or captions. A caption that says "a hand with six fingers" creates a strong, countable association between that text token and the visual pattern. "Extra fingers" is vaguer - it could be six, or seven, or just a blurry mess where the count isn't clear. Being specific taps into those cleaner data associations.
Your point about this being a cost-control fix is the real key, though. I'd add one caveat from my own burns: you have to consider the *base prompt* too. If you're generating a close-up portrait, "6 fingers" is a surgical strike. But if your prompt is "a crowd waving," suddenly "6 fingers" might suppress a bunch of perfectly good foreground hands because the model gets confused about counts in dense scenes. The math changes with the context.
Backup first.