Replicate's six prediction statuses vs Sume's five job statuses

Replicate predictions move through starting, processing, succeeded, failed, canceled and aborted; Sume jobs move through queued, processing, completed, failed and canceled. Replicate's starting has no direct Sume name and aborted has no Sume equivalent, because Sume has one canceled state.

Replicate's definitions are on its prediction lifecycle page; Sume's are in Jobs and results and Errors and rate limits, read 2026-10-02.

What does each Replicate status mean?

starting means the prediction is starting up; the page says that if it lasts more than a few seconds it is usually because a new worker is being started. processing means the model is actively running. succeeded and failed are the normal ends. canceled means the user canceled it or it exceeded its deadline after starting. aborted means it exceeded its deadline before it could start.

How do they map to Sume?

The closest mapping is below. The starting row is an inference from the descriptions, not something either vendor states.

Where does the mapping break?

Replicate bills differently for aborted (no charge) and canceled after a start (runtime billed). Sume instead reserves a USD estimate at submit time, captures it on success and releases it on failure or cancellation before capture, and cancel after generation starts is refused with a 409.

Sume also lets a client skip the status string entirely: the status payload has terminal and result_ready booleans, and a sume_status field. A queue-shaped status field (IN_QUEUE and similar) is kept for ports from other queue APIs, but it is not a Replicate-shaped field.

What does the port code look like?

Branch on terminal, then on sume_status. Treat failed as an error object, not a string: Sume exposes a public category, stage, retryability and next action rather than raw provider payloads. For the endpoint mapping, see Sume vs Replicate.