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.

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.
| Question | Vidu | Sume |
|---|---|---|
| Failed generation | No credits consumed | Reservation released or refunded where applicable |
| Content-moderation rejection | No 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 page | Estimated price reserved at submit |
| Cancel | Not covered on the pricing page | POST /v1/jobs/{id}/cancel, only before generation work starts |
| Queueing | Up to 5 concurrent tasks per package; extra tasks are queued | 429 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
- Vidu Q4 image-to-video request, field by field, as a Sume body
Vidu Q4 Preview is not in Sume's video catalog (read 2026-10-09). Map its img2video fields to POST /v1/videos on seedance-2.5 or wan-3.0.
- Vidu task states mapped onto Sume job statuses in Python
Map Vidu task states (created, queueing, processing, success, failed) to Sume queued, processing, completed and failed so an old poller keeps working.
- Vidu, Wan 3.0 and Sume job states in one poller
Vidu says created/queueing/processing/success/failed, Wan says PENDING/RUNNING/SUCCEEDED/FAILED, Sume says pending/in_progress/completed. One mapping table.
- waitForRun or waitForJob? Pick by which Sume endpoint made the id
A Sume run id cannot be read as a job id. Which create endpoint made your id decides waitForRun or waitForJob, with a TypeScript example of each.
Written by Sume