Replicate status succeeded vs Sume completed: map the states

How do Replicate prediction statuses map to Sume job statuses?

Replicate's succeeded is Sume's completed; both have failed and canceled; and the two non-terminal states do not line up exactly. Replicate has starting then processing; Sume has queued then processing. Porting a poll loop is a one-line status mapping plus one place where the meaning of the first state differs.

What does Replicate's reference list?

A prediction's status is one of: starting (the prediction is starting up; if this lasts longer than a few seconds, a new worker is typically being started), processing (the model's predict method is executing), succeeded, failed and canceled (canceled by its creator). The object also carries created_at, started_at, completed_at, a metrics object with predict_time and total_time, and a urls object with web, get and cancel.

What does Sume's job list?

Five statuses in Jobs and results: queued (accepted, waiting), processing (running or being finalized), completed, failed and canceled. The status endpoint also returns the booleans terminal and result_ready, and a queue-shaped status of IN_QUEUE, IN_PROGRESS, COMPLETED, FAILED or CANCELED that never disagrees with sume_status. Poll on the booleans or on sume_status, and do not mix them.

queued is a normal state, not a warning. It means your workspace is at its processing limit, as described in Generation admission. Replicate's starting is about a worker booting; a Sume queued job is waiting for a slot in your plan.

Mapping table

Use this in a shared client that talks to both.

What does a portable poll loop look like?

This normalizes both vendors to one set of names. For Sume, honor next_poll_after_seconds when present and fall back to a growing delay; fetch the result only after completed, because /result answers 409 job_not_completed otherwise.

TERMINAL = {"succeeded": "completed", "completed": "completed",
            "failed": "failed", "canceled": "canceled"}

def normalize(status: str) -> str:
    s = status.lower()
    if s in TERMINAL:
        return TERMINAL[s]
    return "queued" if s in {"starting", "queued"} else "processing"

def next_delay(payload: dict, attempt: int) -> float:
    hint = payload.get("next_poll_after_seconds")
    return float(hint) if hint else min(2 ** attempt, 30)

assert normalize("succeeded") == "completed"
assert normalize("starting") == "queued"
assert next_delay({}, 3) == 8

What differs besides the names?

Cancellation: Replicate exposes urls.cancel on each prediction; Sume's POST /v1/jobs/:id/cancel works only before generation starts and returns 409 job_generation_already_started afterward. Retention: Replicate API predictions lose data after an hour, while Sume results stay readable. And a failed Sume job carries a public error on the job record, so read failures from GET /v1/jobs/:id rather than from /result.