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.

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.
| Meaning | MiniMax task | Sume /v1/videos poll | Sume /v1/jobs status |
|---|---|---|---|
| Accepted, waiting | queued | pending | queued |
| Generating | running | in_progress | processing |
| Result ready | succeeded | completed | completed |
| Failed | failed | failed | failed |
| Stopped | cancelled | cancelled | canceled |
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 examplejob_01HXYZin the docs' examples. - Authentication: a MiniMax bearer token against
https://api.minimax.io; a Sume API key againsthttps://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
- Mirage Tesseract needs local files; Sume needs public HTTPS URLs
Mirage Tesseract runs on local files in an agent environment. Sume avatar and lip-sync inputs must be public HTTPS URLs. How to hand clips between the two.
- Music API has no duration field: steer length in the prompt
Sume's music router rejects duration and duration_seconds. Ask for a 30-second or 2-minute track in the prompt, with section timestamps, and verify.
- Music API metadata field: tag a track job with your own ids
Sume's music request has an optional metadata field, stored on the job and not sent to the provider. Use it to match tracks to your own records.
- Mux direct upload chunks: multiples of 256 KB, UpChunk at ~5 MB
Mux direct uploads need chunks in multiples of 256 KB; UpChunk sends about 5 MB. A chunk-size helper and the upload states to wait on before using an asset.
Written by Sume