Luma failure_reason moderation messages vs Sume generation_rejected

After a Luma Dream Machine job is accepted, a failure shows up as text in the failure_reason field: moderation messages, prompt processing errors, and job execution errors. Sume does not hand you free text to parse. A failed job carries a public error with a category, a stage, retryability, retry-after seconds, a public reason and a next action.

What Luma tells you

Luma lists three moderation strings: Contains blacklisted words, Frame moderation failed and Advanced prompt moderation failed. Two processing strings follow: Prompt processing failed and Failed to read user input frames. The job execution group has Error dispatching job, Job failed (GPU processing failed, contact support) and Error processing callback (contact support).

What Sume tells you

Sume's categories and next actions: validation (fix input), auth (check key and workspace), quota (add funds or lower request cost), queue (retry later with the same idempotency key), generation_unavailable (retry later), generation_rejected (inspect events and fix unsupported input), generation_timeout and worker_timeout (poll status or retry later), runtime_unavailable (retry later, not aggressively) and internal (inspect events and contact support with the request or job id).

Delivery is not the job

The table's last row matters. A Luma callback failure is reported as a job failure string, while Sume keeps webhook delivery state separate from job state: a job can be completed while its delivery is failed or exhausted. Check the job before you assume the work was lost.

Handling both

Four habits cover both vendors.

• Branch on a category or a code, never on a message string.
• Do not show raw provider text to your end users.
• For a rejection, change the prompt or input before any retry.
• Keep the request id in your logs for support.