How Does WaveSpeedAI's Safety Checker Handle Blocked Prompts and Outputs?

Overview

WaveSpeedAI documents that its web-interface Safety Checker is enabled by default and screens generated outputs against its content rules. Model providers may apply additional policies. Because public guidance may not map every moderation outcome to a distinct API state, applications should use the returned status and error message as the case-specific signal rather than assume a platform-wide classification.

Treat moderation as a separate job outcome

Your application should not place every unsuccessful request in one failed bucket. Record at least four outcomes: invalid input, technical failure, safety refusal, and completed output rejected by your own quality review. Store the task ID, model ID, status, error text, attempt number, and whether an output URL was returned.

WaveSpeedAI’s API documents terminal states such as completed, failed, cancelled, and timeout. Billing treatment should be read from the individual task and account record; do not assume that a safety refusal and a technical failure follow the same charging or refund path. Keep user-facing language conditional unless the recorded transaction or support response confirms the outcome.

Decide whether to retry

Retry only technical failures that appear transient. Do not automatically resubmit policy-blocked content or weaken prompts to evade screening. If the reason is unclear, preserve the task ID and error response, then ask support to classify the event.

Build a safer user experience

Tell users why a request cannot continue, offer policy-compliant editing guidance, and keep billing language conditional. Clear states reduce repeated submissions and make moderation incidents easier to audit.