You describe something ordinary, and the tool says no. Nothing about the request seems like it should trip anything. This happens constantly, and the reason is almost never the model.
What is actually in front of the model
Between your description and the thing that makes the image there is usually a classifier: a smaller, faster model whose only job is to score text for categories a human decided to block. It reads your words, produces a probability for each category, and if any crosses a threshold, your request is stopped before the image model ever sees it.
That classifier knows nothing about your intent, your account, or the rest of your session. It sees a short string of text in isolation and makes a judgement in milliseconds.
Why it over-blocks
A classifier can be wrong in two directions. It can let through something it should have stopped, or it can stop something harmless. Those two mistakes have wildly different consequences for whoever operates the service: one produces a news story and a payment processor review, the other produces an annoyed customer.
So the threshold gets set cautiously, and the caution compounds. Each team adds a margin, and the result is a system that blocks a large band of entirely ordinary requests to be sure of catching the small number that matter.
This is why refusals feel arbitrary. They are not arbitrary — they are the predictable output of a system tuned to accept a high false-positive rate.
The words that trip it
Classifiers work on correlation, not meaning. Words that appear near blocked content in training data get weighted, even when they are innocuous in your sentence. Anatomy terms, certain clothing, some settings, and words describing age in any context are all common triggers.
The last one causes the most confusion. Describing anything as small, young, petite or similar can push a score up even in a sentence that is clearly about an adult, because the classifier is pattern-matching rather than reading.
What the refusal tells you
- Instant refusal, no delay: a prompt classifier. Your request never reached the model.
- A delay, then a refusal: the image was probably generated and then scored. The work was done and discarded.
- A result that is obviously evasive: the model itself, steered away during training.
- Refusal on retry of something that worked before: a threshold was changed, not your prompt.
The second case is the one worth watching on a paid service. If generation happened and the result was thrown away, somebody paid for that compute, and on most pricing models it was you.
What to do about it
Rewording works more often than it should, which tells you something about how shallow the check is. Describing the result rather than the act, avoiding the trigger vocabulary, and being specific about the scene rather than the subject all help.
But rewording your way around a classifier is a poor use of your time, and on a per-attempt pricing model it is a poor use of your money. The alternative is a tool that does not put one in your way to begin with, and is honest that the model underneath still has its own limits.
The arithmetic behind the threshold
Picture a classifier running a million requests a day at ninety-nine per cent accuracy, which would be a very good classifier. That still misses a hundred of the thing it was built to catch, and wrongly blocks ten thousand harmless ones.
Whoever sets the threshold is choosing between those two numbers, and they do not carry equal weight. The hundred misses can produce a headline, a processor review, or a regulator letter. The ten thousand false positives produce support tickets. Faced with that asymmetry, every rational operator moves the threshold towards blocking, and then adds margin because the model will drift.
This is why refusals cluster around ordinary requests rather than genuinely edge ones. The edge cases are a small, well-studied set. The over-blocking is the wide band of ordinary language that happens to sit near them statistically.
What a well-built filter would do differently
Very little of the frustration is inherent. Most of it comes from implementation choices that nobody is forced to make.
- Refund the attempt. If a request never reached the model, no compute was spent and there is no honest reason to charge for it.
- Say which part triggered it. Not the threshold or the model, just the span of text — enough to rewrite without guessing.
- Check before taking payment, not after. A refusal that arrives post-charge is a worse experience and a worse look.
- Be consistent between attempts. A threshold that moves silently teaches people the tool is unreliable rather than that their prompt was wrong.
Judging a service on how it refuses is often more informative than judging it on how often. A tool that refuses rarely but charges you for it, with no explanation and no consistency, is a worse deal than one that refuses more and handles it properly.