sume jobs cancel needs --confirm-submit, and only queued jobs cancel

To cancel a Sume job from the terminal, run sume jobs cancel <job_id> --confirm-submit. The flag is the explicit confirmation the CLI wants for this write, because cancel changes data. The cancel itself only succeeds before generation work starts. After that, the API answers 409 job_generation_already_started with details.cancelable: false, and the job runs to completion or fails on its own.

So the command is safe to run on a queue you want to drain, and useless against a job that is already rendering.

Which flag goes with which command

The CLI uses two different confirmation flags, and mixing them up is the usual first error. Paid generation submits take --confirm-paid. The other write commands, cancel and the asset commands among them, take --confirm-submit. The commands below are from the CLI jobs and assets page.

What cancel returns, by job state

The state of the job decides the outcome, not the CLI.

• queued: the job has not started, so cancel succeeds and the reserved amount is released or refunded.
• processing with generation started: 409 job_generation_already_started, details.cancelable: false. Let it finish.
• Already canceled: the cancel is idempotent and returns the same canceled job.
• completed or failed: the job is terminal, so cancel does not apply. The errors page lists job_not_cancelable among the 409 codes for an operation that is not valid for the current status.

Why you would cancel at all

Sume accepts paid jobs as queued while queue capacity remains, so a batch that was submitted by mistake, with the wrong prompt or the wrong model, is mostly sitting in the queue when you notice. Those are the jobs cancel can save. Cancelling queued work also frees accepted capacity, which matters when a submit has just returned 429 queue_full: the generation admission page tells you to cancel queued jobs you no longer need and then retry with the same idempotency key.

Cancel is not a way to stop spend on a job that is already generating. Plan for that by testing a prompt on one job before you fan out a hundred, and by keeping the job ids you submitted, so a recovery script can find them by id later.

Only the creator can cancel

A job belongs to the member whose key created it, and only that member can cancel it. Run the cancel with the same key that submitted the job. The CLI reads the key from your login or from SUME_API_KEY, so check sume auth status before you chase a confusing error.

A small wrapper script

The script reads the status first, cancels, then reads again. Read the first and third outputs side by side: status tells you whether the cancel could work, and the last read confirms the final state. If the cancel returns the 409, the job is past the point of cancellation and the second status will show it still running.

#!/usr/bin/env bash
set -euo pipefail
job_id="${1:?usage: cancel.sh <job_id>}"

sume jobs status "$job_id" --agent --json      # read first
sume jobs cancel "$job_id" --confirm-submit    # the write needs the flag
sume jobs status "$job_id" --agent --json      # expect canceled, or a 409 above

Do not resubmit after a cancel error

A failed cancel does not mean the job is gone. Do not submit the paid request again because the cancel returned a conflict. Recover with sume jobs status, sume jobs events and sume jobs result instead, as the generation workflows page describes.