Runway DELETE /v1/tasks: cancel or erase output vs Sume job cancel

On Runway one call, DELETE /v1/tasks/{id}, does two jobs: it cancels a task that is running, pending or throttled, and it deletes a task in any other status along with its stored output. Sume splits these: POST /v1/jobs/{id}/cancel only works before generation has started, and it never erases a finished artifact.

That difference matters if you clean up after failures, because the same line of code on Runway can discard a video you wanted to keep.

What does the Runway endpoint do for each status?

Runway's reference describes the behavior by status. Running, pending and throttled tasks are canceled. Any other status, which in practice means a task that has already finished or failed, is deleted entirely, and the output data tied to a deleted task is removed from persistent storage. The task id is a UUID passed in the path.

The page does not say whether canceling a running task returns credits, so do not assume it does. Read your usage export or credit balance after a test cancel before you build a cost-saving rule around it. Calls also carry the X-Runway-Version header; Runway supports an older version for four months after a new one ships, so pin the version your SDK sends.

What does Sume's cancel do?

A Sume job cancel is a POST to the job's cancel path. It succeeds only before generation work has started. Once generation has started the API returns 409 job_generation_already_started with details.cancelable set to false, and the job runs to completion. Cancelling a job that is already canceled is idempotent and returns the same canceled job.

Sume's job statuses include canceled as a terminal state, and the cancel URL is part of the job envelope. The jobs page describes cancel as a stop request only; it does not describe cancel as erasing a finished result, so cancel and delete are not the same operation there.

curl -X POST https://api.sume.com/v1/jobs/job_123/cancel \
  -H "Authorization: Bearer $SUME_API_KEY"

How should client code handle the difference?

Write cancel as a request to stop work and treat the response as information, not a guarantee. On Sume, a 409 from the cancel call means the job is already past the point of cancellation, so stop retrying and poll status for the result. On Runway, check the task status before you call DELETE if you want to keep any finished output.

• Runway: GET the task first, and call DELETE only when the status is running, pending or throttled, or when you really intend to erase the output.
• Sume: call cancel, and on 409 job_generation_already_started switch to polling status and fetch the result.
• Both: a client-side timeout does not cancel anything, so cancel explicitly when you stop waiting.
• Both: log the task or job id before you cancel, so you can audit a cost later.

Does canceling save money?

Only when the vendor stops work before it is billed, and the two pages leave that unspecified or conditional. Sume says cancellation succeeds only before generation starts, so the window where cancel helps is the queue: a job waiting behind a concurrency limit can still be stopped.

On Runway, tasks can sit throttled while your parallel-generation limit is full, so a cancel there is the equivalent window. Check each vendor's billing page for how credits are held and released, and test with a single cheap clip before you automate cleanup. See Jobs and results for the Sume statuses and cancel details.