Seedream 5 Pro NSFW: What the Output Check Really Does

Search for why Seedream 5 Pro NSFW prompts fail and you find frustration rather than answers. The reason is structural: a refusal that lands in under a second can come from any of four places, and only one of them is the model itself.

The one most people never learn about is an independent output check that runs after the image is generated. On reAPI it is an explicit parameter, nsfw_checker, and its behavior has a billing consequence worth knowing before you build against it.

TL;DR

• Four layers can block a generation: the model's own policy, an independent output check, a platform filter, and client-side settings.
• nsfw_checker defaults to true and is locked on in the playground. Only direct API callers can set it to false.
• A blocked image is hidden but still billed. The generation happened; the check suppressed the delivery.
• Disabling the check is a separate SKU, priced slightly above the standard rows.
• It does not change the model's own policy. Whatever ByteDance refuses upstream stays refused.
• NSFW and censored are different problems. Filters aimed at one routinely misfire on ordinary subjects, and that failure has a different fix.

Where a refusal actually comes from

The second row is the one that gets misdiagnosed, because it does not look like a refusal from the outside. The model ran. The image exists. The check decided not to hand it over.

That distinction matters for cost forecasting more than for anything else, which is the part the next section is about.

What nsfw_checker does

It is a boolean, it defaults to true, and it governs an output-side check that runs after generation rather than a prompt-side filter that runs before it.

Three consequences follow.

The playground cannot turn it off. The field is locked on in the browser playground by design. Only direct API calls can send nsfw_checker: false.

A blocked image is still charged. This is the operationally important one. The generation consumed compute and produced an image; the check suppressed delivery. From a billing perspective a suppressed generation looks like a successful one. If your pipeline retries on empty output, you are paying twice.

Turning it off is a separate SKU. The disabled-check rows are priced a little above the standard ones, roughly a 6% premium, and they are API-only. Live rates for both are on reapi.ai/models/seedream-5-0-pro.

What it does not do

Being precise here matters, because the parameter name invites an assumption it does not earn.

It does not alter the model's own policy. The upstream model applies its own rules to what it will generate. Turning off the independent output check changes whether a produced image is delivered to you, not what the model is willing to produce in the first place.

Responsibility sits with the caller, not the platform. Sending nsfw_checker: false is a decision about your own integration, and it shifts nothing onto reAPI or the model provider. Exposing a parameter is not an endorsement of what any particular request produces, and it is not permission to generate anything. You remain bound by the model provider's acceptable-use terms and by the law that applies to you and to your users, and you own the consequences of what your integration generates and where it ends up.

It is not a quality or safety upgrade in reverse. Content that would have been withheld is now delivered. If the surface that consumes it is user-facing, you own whatever moderation that surface needs.

Why "it works on one host but not another"

This is the most common confusion in the launch-week threads, and the explanation is boring: not every host runs the same stack.

Two callers on the same nominal model can get opposite results because one is hitting a permissive host with its own moderation, one is on a mobile client that blocks the category outright regardless of model, or one has an account-level toggle the other does not. None of that is the model behaving inconsistently.

The diagnostic is to hold everything constant except the layer you are testing. Run the same prompt through a direct API call with the check on, then with it off. If the result is identical, the block is upstream in the model policy and no parameter will move it. If it changes, you have located the layer.

NSFW is not the same problem as censored

The threads blur these constantly, and they have different fixes.

NSFW names a category of content. Censored describes an act of blocking, which can land on any content at all. Filters tuned for the first routinely misfire on the second: landscapes, fully clothed subjects, clinical or medical phrasing, ordinary product photography with the wrong adjective attached.

If a plainly safe prompt is being refused, you have a false-positive problem, not a policy problem. Rewording usually fixes it, and it is worth trying before concluding that a model became stricter.

Calling it

Standard call, check on. This is what the playground sends and what most integrations should use:

curl https://reapi.ai/api/v1/images/generations \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedream-5-0-pro",
    "prompt": "editorial portrait, window light, shallow depth of field",
    "size": "2048x1152"
  }'

API-only variant with the independent output check disabled:

curl https://reapi.ai/api/v1/images/generations \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedream-5-0-pro",
    "prompt": "editorial portrait, window light, shallow depth of field",
    "size": "2048x1152",
    "nsfw_checker": false
  }'

Two platform rules apply either way. Media inputs are public http(s) URLs only, no base64. And every call returns exactly one image, so there is no n to batch with. Request and response shapes are in the reapi.ai/docs/seedream-5-0-pro reference.

Building around it

Do not retry on empty output blindly. A suppressed generation already billed. A retry loop that treats "no image" as "try again" doubles the cost of the exact requests most likely to be suppressed again.

Log which layer fired. Distinguish a model-side refusal from a withheld delivery in your own telemetry. They have different remedies and conflating them makes the failure rate look like one problem.

Decide the check per route, not per account. An internal tool and a user-facing feature have different requirements, and the parameter is per-request.

Keep your own moderation where output reaches users. If a surface shows generated images to people, that surface needs its own policy regardless of what any upstream check did or did not do.

FAQ

Does Seedream 5.0 Pro allow NSFW content?

The model applies its own policy to what it will generate, and that policy is not something a request parameter overrides. What nsfw_checker controls is an independent check on delivery of the generated image, not the model's willingness to generate it.

What does nsfw_checker: false actually change?

It disables the independent output check that would otherwise withhold a generated image. It does not change the model's own rules. Responsibility for the request and for whatever it produces stays with the caller: exposing the parameter shifts no obligation onto the platform, and the provider's acceptable-use terms and applicable law continue to bind you.

Can I disable the check in the playground?

No. It is locked on in the browser playground. Only direct API callers can send nsfw_checker: false.

Am I charged when an image is blocked?

Yes. The generation ran and consumed resources; the check suppressed delivery. A blocked result bills like a successful one, which is why blind retry loops get expensive.

Does disabling the check cost more?

Yes, it is a separate SKU priced modestly above the standard rows, and it is API-only. Live rates are on the model page.

Why does the same prompt work on one platform and fail on another?

Because hosts run different stacks: some add their own filters, some clients block categories regardless of model, and account-level settings vary. That is a platform difference, not model inconsistency.

My prompt is clearly safe and still gets refused. Why?

That is a false positive rather than a policy decision. Filters tuned for one category misfire on landscapes, clothed subjects, and clinical phrasing. Rewording usually resolves it.

Is image editing filtered more strictly than text-to-image?

Reference-driven editing has generally been enforced more tightly than plain text-to-image across this model family, so a workflow that passes on generation can still be refused on an edit.

Knowing which layer said no

The useful shift is to stop treating a refusal as one event. A generation that does not reach you may have been declined by the model, withheld by an independent output check, filtered by the host, or blocked by a setting in the client, and those four have different fixes and different costs.

On reAPI the second of those is a parameter rather than a mystery: nsfw_checker, defaulting to on, locked in the playground, disableable only from the API, priced as its own SKU, and billing you whether or not the image is delivered. Knowing that is what turns Seedream 5 Pro NSFW troubleshooting from guesswork into a two-call test — and knowing that the parameter changes delivery rather than policy is what keeps the conclusion honest.

References

1. BytePlus. ModelArk — Seedream 5.0 Pro model documentation and parameters. Retrieved July 2026 from byteplus.com/en/modelark
2. reAPI. Seedream 5.0 Pro endpoint reference. Retrieved July 2026 from reapi.ai/docs/seedream-5-0-pro

Further reading

• reAPI. Seedream 5.0 Pro price. reapi.ai/blog/seedream-5-0-pro-price
• reAPI. Seedream 5.0 Pro bugs and fixes. reapi.ai/blog/seedream-5-0-pro-bugs-and-fixes
• reAPI. Model catalog. reapi.ai/models