FLUX safety_tolerance 0 to 5, and what Sume does instead

On BFL's API, safety_tolerance sets moderation sensitivity: 0 is the strictest, FLUX.2 endpoints accept up to 5, and the default is 2. Sume exposes no equivalent. Sending safety_tolerance to a Sume image model is rejected with 400 unsupported_parameter, and policy refusals surface as content_policy_rejected.

BFL ranges are from its errors page; Sume behavior is from Image generation and the OpenAPI document, both read 2026-10-01.

What are BFL's safety_tolerance ranges?

Lower values filter more aggressively; higher values let more through. A value above an endpoint's maximum returns a 422 validation error.

What does Sume do with the parameter?

Sume's image docs say a request that sets a parameter the selected model does not list is rejected with 400 unsupported_parameter rather than silently dropped. They also say allowed_passthrough_parameters is empty for every endpoint in v1, so provider-specific keys do not pass through. List what a model accepts with GET /v1/images/models.

How do refusals show up on Sume?

The OpenAPI schema describes a machine-friendly public_reason on job errors, with examples including generation_rejected, image_content_rejected and content_policy_rejected. Group on that field in your client. For another model's handling of the same situation see GPT Image 2.5 moderation low.

What should I change in my code?

Remove safety_tolerance from requests you send to Sume, and handle content_policy_rejected by editing the prompt or reference rather than retrying the same request.