Budgeting a one-minute Seedance sequence shot by shot

Updated 2026-10-02

A 60-second Seedance clip is the easy case, and the table you find for it is a floor. A 60-second sequence is usually a dozen shots of three to eight seconds each, each with its own acceptance rate, some run at a draft tier and some at a premium one. Pricing it as one long clip hides the three things that actually decide the total: how many seconds you generate beyond the 60 you keep, which shots go to which variant, and how often each shot has to be redone. This page is a way to build that budget from the shot list.

Start from the shot list, not the runtime

List every shot with three attributes: its requested duration, the variant or tier you will run it on, and a difficulty class that sets its expected acceptance rate. A simple two-class scheme works for a first pass: "easy" (static or simple camera, single subject) and "hard" (several subjects, fast motion, hands, text). A 60-second sequence might be a mix of both, and the hard shots will usually drive the retry cost.

For shot i define L(i) as requested seconds, r(i) the per-second rate for its variant and resolution tier at the host you expect to use, and k(i) its acceptance rate (fraction of generated clips you keep). Billing happens once at job creation from the requested duration, polling is free and upstream failures are not billed, so:

shot_cost(i) = r(i) x L(i) x f / k(i)

sequence_cost = sum over shots of shot_cost(i)

where f is one plus the platform fee. The sum of L(i) across shots should be at least 60 seconds, and usually more, because you trim handles at each cut. That trim overhead is the first hidden multiplier: if you request an extra second per shot for editing room across N shots, you pay for N extra seconds.

The live numbers

The table gives the cost of 5 s, 10 s and 60 s clips at the cheapest host for each Seedance row. Use it for unit costs, and to see how far apart the variants are; do not use the 60 s row as the sequence total.

Computed from each model's cheapest current host per resolution tier, before VideoRouter's 2% platform fee. Built 2026-10-02 from live data. Failed upstream jobs are not billed; re-generations are, so multiply by your retry rate.

The pricing page shows the cheapest versus priciest host for each row, and rates can change, so re-check before quoting a figure to a client.

Mixing tiers: drafts cheap, finals premium

A sequence is a natural fit for a two-stage workflow. Each shot is explored on a cheaper variant or lower resolution tier until the composition and motion are right, then the approved version is re-rendered once at the quality you will ship. For shot i with d(i) draft attempts:

shot_cost(i) = d(i) x r_draft x L_draft(i) x f
             + r_final x L(i) x f / k_final(i)

Two things are worth noticing. Draft clips can be shorter than the final if you only need to judge framing and motion, which cuts L_draft. And the final stage's acceptance rate k_final should be higher than a cold-start rate, since you are re-rendering from inputs that already worked in draft, though this is something to verify on your own material, not assume. The full reasoning for the tier assignment is in the Mini vs Fast vs Full strategy.

A symbolic example

Take a sequence of N shots averaging L seconds, with a fraction h of them "hard". Suppose easy shots are accepted at rate k_e and hard shots at k_h with k_h < k_e. Ignoring drafts, on a single variant at rate r:

sequence_cost = N x L x r x f x [ (1 - h) / k_e + h / k_h ]

The bracket is your average retry multiplier. Notice that raising the hard share h moves cost much more than raising the easy share, because 1 / k_h is the larger term. This is why a single "retry multiplier" for the whole project is a poor model: two sequences of the same runtime can differ widely in cost purely by shot mix. Fill in your own values with the calculator, running the unit cost for each variant.

Practical steps for a first budget

1. Write the shot list with requested durations including trim handles.
2. Tag each shot easy or hard, and pick draft and final variants.
3. Run a sample of each class on a capped key and record acceptance and draft attempts.
4. Compute shot_cost per shot and sum; add a contingency for shots that turn out harder than tagged.
5. Compare against the unit costs in the table to catch arithmetic slips.
6. Re-run when the shot list changes, since a late extension of three shots costs three shots' worth of retries, not just three shots' seconds.

Edge cases

• Duration snapping. A requested duration may be snapped to a value the model supports. Check what the model accepts before you plan odd lengths, and bill your plan on the snapped value.
• Continuity shots. If you chain shots using a start frame from the previous one, a rejected shot can force you to redo what follows. Include that dependency in your acceptance estimate.
• Host choice. The same variant can cost differently across hosts; unpinned requests go to the cheapest healthy host, as explained in why Seedance prices vary. A model/host suffix is a soft preference, so for a hard pin use provider.only with allow_fallbacks set to false.

For the single-clip version of this maths, see Seedance API cost per minute, and the cost page for clip costs by length. To measure acceptance on your own shots, create a key and set a monthly cap first.

Frequently asked questions

Keep reading

• How to Reduce Your Seedance API Cost — Five Practical Levers
• Seedance API Cost Per Minute: Budget Formula & Retry Math
• Seedance vs Kling API Pricing: A Fair Cost Comparison
• Seedance 2.0 Mini vs Fast vs Full: A Cost Strategy for Teams