Seedream 5.0 censorship: what a blocked image looks like on Sume

Seedream requests through Sume run with the provider's safety checker enabled, and Sume gives you no request field to turn it off. Sume's docs define no error code dedicated to a content refusal, so treat one as an ordinary failed generation: it is not billed, and you read the failure from the response or the job. This post covers only Sume's behavior, not any model's policy.

Can I disable the safety checker on Seedream?

No. In the request builders for Seedream 5.0 Lite, 4.5 and 4.0, Sume sets enable_safety_checker: true. The catalog lists allowed_passthrough_parameters as empty for every endpoint, so provider.options must be omitted or empty and there is no route to send a provider-specific flag.

What does a refused generation return?

The docs describe failures by request path, not by cause. The table shows what each path returns; which one a safety refusal takes is not documented, so read the actual response.

How do I find out why a job failed?

Send mode: "async", then read GET /v1/jobs/{id}/status and the events at GET /v1/jobs/:id/events. A failed job carries a category, a stage, a public reason and a next action. The category list, including generation_rejected, is in Errors and rate limits; the docs do not say which category a safety refusal lands in.

curl -X POST "https://api.sume.com/v1/images" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "bytedance-seed/seedream-5-lite",
    "prompt": "a red panda astronaut floating in space",
    "mode": "async"
  }'

What should I do when a prompt keeps failing?

Rule out your own request first: a wrong parameter returns a 400, not a refusal. If the same prompt fails on repeat, reword it and retry, or try another catalog model. Failed generations cost nothing, so retries only cost time. When you write to support, include the request id from the error body, as the docs ask.

How should my app retry a failed generation?

Retry with care. The docs say not to retry unsafe submit requests without an Idempotency-Key, and to back off on 429 using retry-after when it is present. For a prompt that fails for content reasons, an identical retry is unlikely to change the result, so vary the prompt instead of looping.

Log the request id from every failure. It is safe to share with Sume support, and it is the quickest way to have a specific failed request looked at. Do not include API keys or signed URLs when you write in.

Does a refusal cost anything?

Not by the docs' rule: a generation is billed only when it completes, and a failed or cancelled one is not billed. A client that disconnects early is also billed as a failed generation, which means not at all.