Failed video-trim or video-filter job: is the $0.02 refunded?

When a paid Sume job is accepted, Sume reserves the estimated amount at submit. A successful completion captures it, and the docs say failed jobs and failed queue admission release or refund the reservation where applicable. For video trim and video filter the reservation is $0.02 per job.

That wording is deliberately cautious, so this page separates what the docs state from what they leave open. Everything below was read on 2026-10-10 from the Generation admission, Errors and rate limits, Video trim and Video filter pages.

The ledger in three steps

Reserve happens at submit, and only when Sume accepts the request. Capture happens when the job completes successfully. Release or refund happens for a failed job or a failed queue admission. A balance that dips while a job runs and then settles is the reserve step, not a second charge.

The trim API adds one detail in its OpenAPI text: the job is reserved at $0.02 and captured at the pass's own Modal compute (list times 1.25 plus the platform fee), never above the reservation. So $0.02 is the ceiling for a trim, and the capture cannot exceed it.

What happens at each failure point

The table keeps the docs wording. It does not promise a refund timing, and it does not list every per-case rule. If a balance looks wrong after a failed job, send the request id from the error body to support; the docs ask you to share that id and never an API key or a signed URL.

Retrying without paying twice

Every paid media write needs an Idempotency-Key. If your client times out, send the same key again instead of building a new request. The docs say not to resubmit a paid request only because a local worker timed out, and not to retry unsafe submits without a key.

In sync mode the handler waits at most 30 seconds. If the job is not done by then you get 202, and you poll GET /v1/jobs/:id/status instead of sending the submit again. The 202 is not a failure and not a second job.

Ways to keep the risk at zero

Video filter has a free check route, POST /v1/video-filter/check. It runs the schema, allowlist and source preflight without creating a job, reserving credits or booting a worker. A program can still fail later on a bad expression or memory, so the check lowers the risk but does not remove it.

For trim there is no check route. The cheap protection is to validate the inputs yourself: send start and exactly one of end or duration, keep end after start, keep the source at 1800 seconds or less and the output at 900 seconds or less, and use a media.sume.com URL from your own workspace. Each of those mistakes has its own stable 400 code, so a rejected request is a clear signal rather than a silent bill.

A quick budget rule

For a batch of 100 trims, hold $2.00 in balance: 100 x $0.02. If a few fail, the held amount comes back as the docs describe, and your retries use the same keys. Check GET /v1/balance and the generation_limits snapshot before you submit a large wave, because a full queue returns queue_full even when the balance is fine.