Understand Seedance video API pricing before you submit

A useful video price is one you can calculate before creation and reconcile after the task completes. SeedanceLink’s standard quote uses the requested duration and the selected resolution tier. The model page, its estimator, and the table below read the same approved retail catalog. This avoids a separate blog price list silently drifting away from the product.

The basic calculation is requested seconds × the selected model-and-resolution rate × your applicable group multiplier. It describes the retail quote for your API request, not the supplier’s final charge. Do not assume that another account’s rate or an upstream website’s promotion applies to your key. Save the billing fields returned for your own task.

Four- and ten-second estimates

For example, a four-second Seedance 2.0 task at 480p has a standard estimate of USD $0.36. Ten seconds at the same tier is USD $0.90. The corresponding Seedance 2.5 examples are USD $0.52 and USD $1.30. Increasing resolution changes the per-second rate as shown in the table; changing only the prompt does not change the duration value you requested.

Every duration in this table is within both model ranges. Seedance 2.0 accepts four to fifteen requested seconds; Seedance 2.5 accepts four to thirty. The estimator refuses an invalid duration rather than presenting it as a valid quote. Always send duration and resolution explicitly when checking a cost example: their omitted defaults are five seconds and 720p.

A reservation is part of the task lifecycle

When a creation request is accepted, the quote is reserved so the system can fund the task without waiting for the finished video. A held reservation is not an extra charge in addition to the eventual successful task. It records the amount allocated to that one task while generation is pending.

A successful task captures its reservation. A known failed or rejected generation releases the reserved amount back to the account’s API balance. This is a video-task credit adjustment, not an automatic refund to a bank card or a reversal of an earlier recharge. Recharge orders and generation billing are different records with different purposes.

Handle an uncertain submission carefully

A 202 response with needs_reconcile is still a receipt for a local task. It means the system cannot safely confirm the submission outcome and retains the reservation for review. Repeating the creation request could start a second job while the first one is being resolved. Keep the receipt, query its ID, and ask for help if it remains unresolved.

The distinction also matters in your user interface. Show a pending or review state instead of marking every non-final response as a failed payment. An HTTP response alone does not replace the task status and billing fields. Display the amount quoted for the saved task rather than recalculating historical bills using a price that may later change.

Billing questions