MiniMax task statuses vs Sume job statuses: a mapping table

MiniMax reports queued, running, succeeded, failed, cancelled. Sume job status uses queued, processing, completed, failed, canceled. Map them correctly.

5 min readSume
All posts

MiniMax lists task statuses queued, running, succeeded, failed and cancelled; Sume lists two vocabularies for the same video job, queued, processing, completed, failed, canceled on the jobs routes and pending, in_progress, completed, failed, cancelled on /v1/videos polls. If you port a MiniMax H3 poller to Sume, change the status strings and the spelling of cancelled.

MiniMax's values are from Create Video Generation Task, read 2026-10-02. Sume's are from Video generation and Jobs and results.

What does each side call each state?

The table lines the three sets up. The meaning is the same, accepted and waiting, being generated, done, failed, stopped, but a poller that compares to the wrong string will loop forever or report success on a failure.

Note the spelling trap: cancelled with two Ls appears in the video guide's status table, while the jobs page uses canceled. A robust client treats both as terminal.

Status vocabularies (read 2026-10-02)
MeaningMiniMax taskSume /v1/videos pollSume /v1/jobs status
Accepted, waitingqueuedpendingqueued
Generatingrunningin_progressprocessing
Result readysucceededcompletedcompleted
Failedfailedfailedfailed
Stoppedcancelledcancelledcanceled

Which Sume endpoint should my poller read?

Both read the same job. The video guide says the same job is also visible at GET /v1/jobs/{id}/status and GET /v1/jobs/{id}/result, so you can use the OpenRouter-shaped poll URL that the submit response returns, or the generic jobs routes that work for every Sume model. Pick one and stay with it in a given client.

On the jobs routes, a terminal flag and a result_ready flag tell you when to stop and when to fetch the result, per the communication-modes table. That is less error-prone than string comparison.

What is a safe normalizer?

Normalize everything to your own three states and compare only those. The function accepts every spelling in the table.

DONE = {"succeeded", "completed"}
FAILED = {"failed"}
STOPPED = {"cancelled", "canceled"}

def normalize(status: str) -> str:
    s = status.lower()
    if s in DONE:
        return "done"
    if s in FAILED:
        return "failed"
    if s in STOPPED:
        return "stopped"
    return "waiting"  # queued, running, pending, in_progress, processing

assert normalize("in_progress") == "waiting"
assert normalize("canceled") == "stopped"

What else changes besides the strings?

The React Query polling post shows the same stop condition in a front-end client.

  • Identifiers: MiniMax returns a task_id; Sume returns a job id, for example job_01HXYZ in the docs' examples.
  • Authentication: a MiniMax bearer token against https://api.minimax.io; a Sume API key against https://api.sume.com.
  • Webhooks: Sume sends terminal events only (job.completed, job.failed, job.canceled), and recommends keeping polling as a backup.
  • Retries: Sume accepts an Idempotency-Key; a replay returns the original job. Do not resubmit because your own process timed out.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume