Vidu: failed and moderated videos use no credits. What Sume does

Vidu's pricing page says failed generations, moderation rejections included, use no credits. Sume reserves at submit and releases on failure. How to check each.

5 min readSume
All posts

Vidu's pricing page states that videos that fail to generate do not consume credits, and that this includes failures caused by content-moderation rejection. Sume's rule is similar in effect but different in mechanism: it reserves the estimated price when a job is accepted, captures it on success, and releases or refunds the reservation for failed jobs and failed queue admission where applicable.

Failure billing, as stated on each page (read 2026-10-09)
QuestionViduSume
Failed generationNo credits consumedReservation released or refunded where applicable
Content-moderation rejectionNo credits consumed (stated)Not stated as its own case; check the job's failed status and error
When is money held?Not stated on the pricing pageEstimated price reserved at submit
CancelNot covered on the pricing pagePOST /v1/jobs/{id}/cancel, only before generation work starts
QueueingUp to 5 concurrent tasks per package; extra tasks are queued429 queue_full when the workspace has no accepted capacity left

What the difference means for you

With a reserve-then-capture model your balance dips while a job runs, so a 402 insufficient_credits can occur at submit even if your final spend would have fit. The Sume docs say a 402 means Sume cannot reserve the estimated cost, and the fix is to wait, top up or submit a cheaper request. With Vidu's credit package the balance is simply decremented when the clip is generated, and a failed one costs nothing.

Neither page says that every possible failure is free in every circumstance, so in both cases log the task id, the final status and the cost field, and reconcile them at the end of the day.

A reconciliation check on Sume

After each job, read the finished job and compare your wallet with the reserved estimate. The jobs docs describe GET /v1/jobs/:id/status and GET /v1/jobs/:id/result, and the errors docs say failed jobs show public error metadata including category, stage and retryability. Use an Idempotency-Key on submits so a retry returns the original job instead of creating a second billable one.

  • Submit with an Idempotency-Key header.
  • Poll the job until status is completed, failed or canceled.
  • On failed, read the error metadata, then retry only when it says the failure is retryable.
  • Compare the wallet before and after for any job you want to audit, since the docs say failed jobs release the reservation where applicable.

Vidu is not on Sume

Sume does not list Vidu, so the Vidu rule never applies to Sume jobs. It matters if you use both: keep per-vendor logs, because Vidu's unit is credits at 0.03125 RMB each and Sume's is USD.

Queues and capacity

Both services queue work rather than reject it outright. Vidu says up to 5 concurrent tasks run at once and extra tasks wait in a queue, and that load can lower your available concurrency in rare cases. Sume's admission docs describe a queue limit per workspace: past it you get 429 queue_full, and the advice is to wait for jobs to finish, cancel queued jobs you no longer need, then retry with the same idempotency key.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume