Seedance 2.5 Draft Final: 5 Clips Tested and the Real Cost Math

Seedance 2.5 picked up a second endpoint this cycle, and it is the first one ByteDance has shipped that exists purely to manage your bill. You render a cheap 480p draft with draft: true, you get a draft_task_id back, and you send that id to seedance-2.5-draft-final to get the same shot again at full 1080p. Draft cheap, finalize once, spend the expensive money only on the take you approve.

That is a good pitch. It is also the kind of pitch that falls apart the moment you do the arithmetic, so I ran five clips through both halves of the workflow and logged the x-cost header on every single call. Thirteen billed fires, one free failure, $23.17 of credit, and a control render I added specifically to try to prove the feature redundant.

Here is the answer before the evidence, because it is not the answer the product page implies. Finalizing a draft costs exactly what rendering that same clip straight to 1080p costs. Not a discount, not a surcharge, the same number to the token. So if you draft once and finalize once, you have spent about 18% more than if you had skipped the draft entirely. Seedance 2.5 Draft Final does not make video cheaper. It makes throwing video away cheap, and those are very different claims.

How the two halves actually connect

The flow is two calls against two different slugs, and the thing that joins them is a single opaque id. On seedance-2.5 you set draft: true and leave resolution at 480p, which is the only resolution a draft accepts:

curl -X POST "https://api.segmind.com/v1/seedance-2.5" \
  -H "x-api-key: $SEGMIND_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "prompt": "...",
    "duration": 4,
    "resolution": "480p",
    "aspect_ratio": "16:9",
    "seed": 12345,
    "draft": true
  }' -D headers.txt -o draft.mp4

Note the -D headers.txt, because that is the part the docs understate. The v1 response body is the raw MP4. The id you need is not in it. It arrives as a response header, X-Draft-Task-ID, and if you are using a client that throws headers away after checking the status code then you have just paid for a draft you can never finalize. Mine came back as cgt-20261002230927-h64te. The llms.txt mentions video.draft_task_id on the /v2 JSON envelope, which is the friendlier path if you are already on v2.

Then you hand that id over, and this call takes almost nothing else:

curl -X POST "https://api.segmind.com/v1/seedance-2.5-draft-final" \
  -H "x-api-key: $SEGMIND_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "draft_task_id": "cgt-20261002230927-h64te",
    "output_codec": "h264"
  }' -o final.mp4

Four parameters exist on the finalize endpoint and only one is required. Prompt, duration, aspect ratio, seed, reference media and the audio setting are all inherited from the draft and cannot be overridden. The three optional ones only touch the container: output_format, return_last_frame and output_codec. That is the deal: you get no second creative decision, which is precisely why the output is predictable.

What the price table is really saying

The finalize endpoint publishes its prices as a flat lookup table rather than a rate, which makes the important fact easy to miss. Differencing consecutive rows gives you the per-second rate, and it lands on $0.58757 per second for 1080p 16:9. The direct Seedance 2.5 rate card charges $0.5876 per second for a 1080p 16:9 text or image render. Those are the same number.

I wanted that confirmed in billing rather than in a table, so I reconciled the headers. A 4-second 1080p finalize reported 196,425 completion tokens and billed $2.35513575, which is $11.99 per million: exactly the published 1080p token rate. The 480p drafts reported 38,830 tokens and billed $0.4259651, which is $10.970 per million. Both tiers follow one formula:

tokens  = (width x height / 1024) x (24 x duration + 1)
cost    = tokens x rate       # $10.97/M at 480p and 720p, $11.99/M at 1080p

1920 x 1080 / 1024 is 2025, times 97 frames is 196,425. That matched the header to the token on every fire. The extra frame is real: a 4-second clip at 24fps bills 97 frames, not 96, which is why short clips carry a slightly higher per-second rate than long ones. It also means the published tables are a rounded convenience, and they round in both directions. A 4-second 1080p clip actually bills $2.35514 where the table says $2.35028, so the table is 0.21% low. A 10-second clip actually bills $5.85142 where the table says $5.87570, so there the table is 0.41% high. Both sit inside the 1 to 2% tolerance the pricing notes already warn about, and neither will hurt you at this volume. But if you are reselling generations, bill off the header and not off the table.

The break-even is 1.22 takes

Once you accept that the finalize is priced identically to a direct render, the whole economic question collapses into one variable: how many attempts does it take you to get a shot you would actually ship? Call that k. The draft path costs k drafts plus one finalize. The direct path costs k renders at 1080p. Set them equal and k works out to 1.22.

In plain terms: if you nail every shot first try, the drafts are pure overhead and you should not be using this endpoint. If you need two or more attempts, which is the honest number for anything with specific motion in it, the draft path is cheaper immediately and the gap widens fast. At five takes you are spending a third of what the direct path costs. A 480p draft is 5.5 times cheaper per second than a 1080p render, so every rejection you move from the expensive tier to the cheap one is worth 82% of its price.

That is the real feature. Not cheaper video: cheaper mistakes.

Clip 1: is the final really the draft, or just another take?

Everything above is bookkeeping. This is the test that decides whether the feature is worth anything, because there is an obvious cheaper way to do the same thing: render at 480p the ordinary way, keep your seed, and re-render at 1080p when you like what you see. If that works, draft_task_id is a convenience wrapper and nothing more.

So I rendered clip 1 three times. Once as a 480p draft. Once as the finalize of that draft. And once straight to 1080p with the same prompt and the same seed, 12345, with no draft in the loop at all.

Play the first two and you are watching one video at two sizes. The wok sits at the same angle, the ladle enters on the same beat, the rice leaves the pan at the same frame and lands back in it at the same frame. To put a number on it I downscaled both to a common 64 x 64 greyscale grid and correlated them frame by frame. The draft and its finalize score a mean of 0.959 across all 97 frames, never dropping below 0.94. Same frame count, same audio, same everything that matters.

Now the control. Same prompt, same seed, rendered directly at 1080p: mean correlation against the draft of 0.257, and against the finalize 0.257. It is a competent clip of the same subject and it is a completely different take. Different framing, different timing on the toss. The seed did not carry the composition across a resolution change, which is a known Seedance behaviour and the entire reason this endpoint has to exist.

Then the clock, which I did not expect. The draft took 65s and the finalize took 70s, so the two-step path spent 135s end to end. The direct 1080p control took 160s by itself and billed $2.3551, the same $2.3551 the finalize billed, down to the last digit and the same 196,425 tokens. So the two-step route is not a latency tax you pay for the privilege of reviewing. It is faster to a finished 1080p clip than going direct, and it hands you something watchable after the first 65s.

Clip 2: vertical inherits cleanly, and the default codec bites

Aspect ratio is inherited, which means the only place you can choose vertical is the draft. I drafted this one at 9:16 and finalized it on the default output_codec: auto on purpose, to see what actually arrives.

The geometry came through properly: 1080 x 1920, a real portrait file rather than a landscape render padded into a vertical box, which is a failure mode I have seen on this model family before. Correlation against the draft was 0.988, in the same band as every other clip here. It also shows the model taking a liberty I only noticed because the draft was cheap enough to sit and study: I asked for a robot marching across a desk and got one marching away from camera across floorboards. That is a prompt problem, and finding it for $0.43 rather than $2.36 is the entire pitch working as advertised.

The codec is the part to write down. The file that came back on auto is HEVC Main 10, 10-bit 4:2:0, in an hvc1 container, at 23.6 Mbps against 6.2 for the H.264 version. It is the higher-fidelity master and the right choice if the clip is headed into a grade, but it will not play in Chrome or Firefox on Windows, which is where a good share of your reviewers are. The version embedded above is that same master re-encoded locally to H.264 so it plays here. If I were shipping this to a browser I would have passed output_codec: h264 and let Segmind do it, which costs nothing extra and adds a few seconds.

Clip 3: ten seconds and two shots, inherited intact

Duration is inherited too, so I wanted to know whether a multi-shot draft keeps its cut in the same place. I drafted a ten-second, two-shot prompt using the Shot 1: / Shot 2: grammar.

The cut survives. Both files run 241 frames, the transition from throwing to lifting happens at the same moment in each, and the correlation held at 0.976 even across the shot change, which is where I expected it to fall apart. The finalize billed $5.8514 against 488,025 tokens, which is 2025 per frame again.

This is also where the cheap-iteration argument gets loudest. A ten-second 1080p render is $5.85 a throw. The draft is $1.06. If a ten-second two-shot sequence takes you three attempts to get the beats right, which is realistic, you are choosing between $17.55 and $9.03 for the same finished clip.

The model did take liberties here too: I asked for a kick wheel and a lump of clay, and got an electric wheel and a cylinder already half-formed. Again, the kind of thing you want to find at draft prices.

Clip 4: the last frame comes back in a header, and the draft's is useless

return_last_frame exists on both endpoints and is how you chain shots into a longer sequence: you take the final frame of one clip and feed it to the next generation's first_frame_url. I set it on the draft and on the finalize to see what each gives you.

Two things the docs do not tell you. First, on the v1 endpoint the frame does not come back in the body, it comes back as an X-Last-Frame-URL response header. The llms.txt only documents video.last_frame_url on the v2 JSON envelope, so if you are on v1 and looking in the payload you will conclude the parameter is broken.

Second, that URL is presigned and short-lived: X-Tos-Expires=86400 and X-Tos-Max-Requests=100, so 24 hours and a hundred fetches. Copy it to your own storage in the same job or you will lose it.

And the detail that actually matters for chaining: the draft's last frame comes back at 854 x 480, the draft's own resolution. The finalize's comes back at 1920 x 1080. If you are chaining shots for a 1080p sequence, ask for the last frame on the finalize, not on the draft. A 480p still fed into the next shot's first_frame_url is a soft first frame you will have to live with.

The last frame of the finalized clip, returned as a separate image at 1920 x 1080, ready to seed the next shot.

Clip 5: three drafts, one finalize, the workflow as intended

The first four clips tested whether the machinery works. This one tests the actual proposition: draft a hard shot several times, review at 480p, finalize only the winner. I fired the same prompt three times at three seeds and committed to finalizing exactly one.

Seed 101 gave me a technically fine clip where the gob of glass is a small bright dot in a mostly black frame. Seed 303 put the glass across half the frame, legible and turning, which is the shot. I finalized 303 and the correlation came back at 0.988, same as everywhere else.

Seed 202 is the interesting one. It ran for 54 seconds and then returned a 400 with blocked_side: output and finish_reason: OutputAudioSensitiveContentDetected. The model rendered the clip, ran a copyright check on the audio track it had generated, and refused to hand it over. Same prompt, same "no music" instruction, different seed, different outcome. The error text is clear that the audio was flagged rather than the prompt, and suggests retrying with generate_audio: false. Billing-wise it cost nothing, which the pricing notes promise for failed generations and which the header confirmed.

So the real arithmetic for this clip: two billed drafts at $0.8519 total, one free failure, and one finalize at $2.3551. Call it $3.21 to land one approved 1080p clip. Running the same three attempts directly at 1080p would have cost $4.71 for the two that rendered and produced the identical keeper. That is a 32% saving, on a review I would have done anyway.

Three things I probed on purpose

Two of these cost nothing and one cost $2.36, and the expensive one is the one you need to know about before you put this in production.

A draft_task_id is not single-use, and it bills every time. I sent the same id from clip 1 to the finalize endpoint a second time. It did not reject it. It rendered the clip again, billed another $2.3551, and handed back a video that correlates with the first finalize at 0.9999: the same frames, the same length, the same audio. Only the encoded bytes differ, because the H.264 pass is not bit-reproducible.

That cuts both ways. It is genuinely useful if you lost the file or want the other codec, since you can refinalize within the seven days and get exactly the same clip back. It is also a trap: any client that retries a POST on a read timeout will cheerfully pay twice for a byte-equivalent video. The finalize endpoint is synchronous and my calls took 34s to 89s, comfortably inside most default timeouts, but if you wrap it in a generic retry decorator you are writing yourself a bill. Make the retry idempotent on your side, because the API will not do it for you.

The two error paths are fast, free and unusually well written. Drafting with resolution: 1080p gets rejected in under a second with "A draft renders at 480p only; omit resolution or set it to 480p." A made-up id gets "Unknown or expired draft_task_id. A draft can be re-rendered for seven days after it was generated." in 0.8s. You cannot validate an id without spending, but discovering a dead one costs nothing.

Every fire, with what it billed

Thirteen billed calls and one free failure, $23.17 of Segmind credit in total. Every figure is the x-cost header on that specific request.

What you cannot do at the finalize stage

Four constraints are worth knowing before you build a pipeline on this, because each one is a place I expected flexibility and did not get it.

You cannot change anything creative. No prompt tweak, no duration change, no aspect ratio switch, no different seed. If the draft framed the shot wrong, the draft is garbage and you render another draft. This is a feature, not a limitation, but it means your prompt iteration has to fully converge at 480p.

You cannot reach 720p through it. The finalize endpoint only outputs 1080p. If 720p is your delivery format, which it is for a lot of social work, this whole workflow is unavailable to you and you are back to rendering 720p directly at $0.2389 per second.

The id expires in seven days. Drafts are not an archive. If your approval cycle runs longer than a week, the id is dead and the draft spend is wasted.

The default codec will break your previews. As clip 2 shows, output_codec defaults to the 10-bit HEVC master, which Chrome and Firefox on Windows cannot decode. Pass h264 for anything watched in a browser.

The video-to-video discount nobody is advertising

There is one case where draft-then-finalize is cheaper per clip even if you never reject a single take, and it is buried in the second half of the price table.

Direct video-to-video on Seedance 2.5 bills your output plus your reference footage. A 5-second 1080p output driven by a 5-second reference is billed as 10 seconds at $0.3519, so $3.52. The finalize endpoint's video_input: true rows differ by $0.351856 per second of output and nothing else. Reference seconds are simply not in there.

So the same job routed through a draft bills $0.637 for the 480p draft, which does pay the reference surcharge at the cheap tier, plus $1.759 for the finalize, which does not: $2.40 against $3.52, a 32% saving on the first take. I did not spend budget rendering this one, so treat it as a table reading rather than a measurement. But the table is unambiguous, and it inverts the usual advice that video-to-video is never the cheap option.

So does it help you control cost?

Yes, with one condition that matters more than the feature itself: it only pays if you actually reject drafts. The endpoint hands you a cheap, faithful preview of an expensive render. If you look at that preview and finalize it every time out of habit, you have built yourself an 18% tax and a second API call. If you look at it and bin one in three, you are saving real money and you will feel it inside a week.

What surprised me is that the cost argument turned out to be the weaker half. The stronger half is that 480p stopped lying to me. Drafting at 480p the ordinary way, by setting resolution: 480p and keeping your seed, gives you a preview of a different video. The draft id makes the preview binding. That changes what a review meeting can decide, and it is worth the 18% even on the runs where the arithmetic says it is not.

Where I would not use it: anything delivering at 720p, anything where the approval loop runs longer than seven days, and single-shot work you have already prompted to death and know lands first try.

FAQ

What is Seedance 2.5 Draft Final?

It is the finishing half of the Seedance 2.5 two-step workflow. You render a 480p draft with draft: true, then send the returned draft_task_id to seedance-2.5-draft-final to get the same shot at 1080p with its audio. The seedance 2.5 draft final endpoint takes no creative parameters of its own.

Does seedance 2.5 draft final cost less than rendering at 1080p directly?

No. It bills at exactly the same per-second rate, $0.58757 for 1080p 16:9, which I confirmed against the x-cost header. You save money only by rejecting drafts instead of rejecting 1080p renders. Break-even is 1.22 takes, so from your second attempt onward you are ahead.

Is the 1080p final really the same shot as the draft?

Yes. I correlated the 480p draft against its 1080p final frame by frame and got a mean of 0.96 across all 97 frames, with the same frame count and the same audio. The same prompt and the same seed rendered straight to 1080p, with no draft in the loop, scored 0.26 against that draft: a completely different take. The draft_task_id is doing the work, not the seed.

How long is a draft_task_id valid?

Seven days from the draft render. After that the draft spend is lost and you have to start again.

Why does my finalized video play as a black frame with sound?

output_codec defaults to auto, which returns 10-bit HEVC at 1080p. Chrome and Firefox on Windows cannot decode it. Pass h264 for anything headed to a browser.

Can I change the prompt, duration or aspect ratio when finalizing?

No. All of it is inherited from the draft, including the seed and the audio setting. Get the shot right at 480p, because the finalize is not a second chance.

Try it

Both halves are live on Segmind with no waitlist and no regional gate: seedance-2.5 for the draft and seedance-2.5-draft-final for the 1080p finish. Start at 4 seconds and 16:9, which is the cheapest finalize tier at $2.35, and keep the X-Draft-Task-ID header from every draft you like. The full rate tables are on the pricing page.