Seedance 2.5 Image-to-Video: First and Last Frame Control (2026)

Seedance 2.5 treats the last frame as a destination, not a hint. Give it both ends of a shot and it arrives at the one you asked for, which is the thing 2.0 Mini would not do.

Endpoint:     POST /v1/videos  ->  202 + polling_url
Field:        frame_images[] with frame_type first_frame / last_frame
Ratio rule:   aspect_ratio is a 400 on 2.5 frame jobs. Omit it, or send adaptive.
Same on 2.0:  no. 2.0-mini accepts aspect_ratio with frames.
Closing frame error, 0-255 mean absolute difference, lower is closer:
              Seedance 2.5 at 720p    2.0
              Seedance 2.5 at 480p    5.4
              Seedance 2.0 Mini       35.9
              two unrelated images    39.0  (the ceiling)
Billed:       $0.11/s at 480p, $0.24/s at 720p, at the text-to-video row
Measured:     2026-08-24, one 5s clip per configuration

Last updated 2026-08-24. Every number below came from POST /v1/videos through ofox on that date. Video model routing changes; re-run the four error cases before copying the validation table into your own code.

How Do You Send a First and Last Frame to Seedance 2.5?

Two elements in frame_images, each tagged with a frame_type. There is no mode switch; the endpoint infers image-to-video from the body.

import base64, json, requests

def data_uri(path):
    return "data:image/jpeg;base64," + base64.b64encode(open(path, "rb").read()).decode()

body = {
    "model": "bytedance/seedance-2.5",
    "prompt": "The woman stops walking on the rain-slicked street, turns toward the "
              "camera, and the shot pushes in to her face. Hand-painted 2D animation style.",
    "duration": 5,
    "resolution": "480p",
    # no aspect_ratio here on purpose: see the next section
    "frame_images": [
        {"type": "image_url", "image_url": {"url": data_uri("wide.jpg")},  "frame_type": "first_frame"},
        {"type": "image_url", "image_url": {"url": data_uri("close.jpg")}, "frame_type": "last_frame"},
    ],
}

r = requests.post("https://api.ofox.io/v1/videos", json=body,
                  headers={"Authorization": "Bearer YOUR_OFOX_API_KEY"})
print(r.status_code, r.json())   # 202 {'id': ..., 'status': 'queued', 'polling_url': ...}

Data URIs work, which matters more than it sounds: it means you can test first-last-frame generation without standing up a public image host first. Then poll polling_url until the status is terminal, which is its own set of traps worth reading before you write the loop.

The prompt still does work here. It is not decoration between two fixed images: it decides what happens on the way, and how many camera moves get spent doing it.

Does Seedance 2.5 Actually Land on the Last Frame?

Yes, and the gap against 2.0 Mini is not subtle. Same two images, same prompt, same duration, same day.

To put a number on it, we pulled frame 0 and the final frame out of each clip, resized both the frame and the source image to 256x144, and took the mean absolute per-channel difference on a 0 to 255 scale. Low is close.

Read the bottom row first. Two images that have nothing to do with each other score about 39. Mini’s closing frame scores 35.9, which is to say it ended somewhere of its own choosing: same rainy palette, different character, different framing. The opening frame is a different story, and both models hold it tightly, which fits the older behaviour we saw on the 2.0 line where the first frame is honoured and the last frame drifts.

Two caveats before you build on this. Each configuration is one run, not a distribution, so treat the ordering as the finding and the exact decimals as one sample. And the difference metric is deliberately crude: it will punish a correct composition that is two frames early. That crudeness is also why the 35.9 is convincing. Nothing that mild could produce a number that close to unrelated.

Why Does aspect_ratio Return 400 on a 2.5 Frame Job?

Because the ratio is derived from the first-frame image, so sending it is an error rather than a redundancy.

POST /v1/videos  {model: bytedance/seedance-2.5, resolution: 480p,
                  aspect_ratio: "16:9", frame_images: [first, last]}

400 invalid_request
"The parameter ratio specified in the request is not valid. For first-frame or
 first-last-frame generation, the output ratio follows the first-frame image."

The part that catches people: our first-frame image is exactly 1280x720, so the 16:9 we sent was correct. It is still refused. The API is not comparing your value against the image, it is refusing to accept a value at all in this mode.

Three things follow, and all three are measured rather than assumed:

So the restriction belongs to 2.5’s frame-based tasks specifically. It is not a rule about video generation, it is not a rule about the whole model, and it is not a rule about the gateway. Code that has worked for months against Seedance 2.0 will start returning 400 on the day someone edits the model ID to 2.5, and the error message will talk about a parameter nobody changed. ByteDance documents this directly. The Seedance 2.5 prompt guide splits tasks into locked and unlocked, puts “Editing, first and last frames, and extension” in the locked group, and describes locked as “the output video’s aspect ratio, and in some cases its duration, are locked”. The same page adds the line that explains our 2.0 result: “Seedance 2.0 does not make this distinction.”

What Else Does the frame_images Validator Reject?

Four shapes, all caught before the request goes upstream. Each came back in roughly a second and cost nothing.

Notice the indexed path in the third one. When you are generating request bodies in a loop, frame_images[0] tells you which element to look at, which is more than most video APIs give you.

All five rejections are live calls against Seedance 2.5. The ffprobe line at the bottom is the three clips that did run, and it is where the 1080p codec change shows up.

The second rule is the one worth designing around. There is no last-frame-only mode, so a pipeline that wants to end on a known image has to also decide where it starts. If you only care about the ending, generate a plausible opening still first and pass both.

What Does an Image-to-Video Clip Actually Cost?

It bills at the text-to-video row for that resolution. The model page prices Seedance 2.5 by resolution and mode, and there is no image-to-video row, so the natural fear is that you land on the “all other combinations” line at $0.568/s. You do not.

Three resolutions, three exact matches. The files came back at 854x480, 1280x720 and 1920x1080, all 24 fps with an AAC track at 32 kHz. Duration lands at 5.04s rather than exactly 5, so bill on the usage.video_seconds field rather than on your own arithmetic.

For comparison, the same request on bytedance/seedance-2.0-mini at 480p billed $0.10 for the clip, which is why Mini stays the right tool for throughput work where nobody is checking the closing frame. It is five and a half times cheaper and, on this task, the difference shows.

Which Resolutions Does Seedance 2.5 Accept?

Ask the pricing table, not the description. The model page currently prints a prose summary saying 480p or 720p, while the pricing table on the same page lists 1080p rows for text-to-video and video-to-video, and a 1080p first-last-frame job ran to completion for us.

That kind of disagreement is normal in the weeks after a resolution tier opens, and the resolution field is the cheapest possible thing to test: send the request, read the status code. A rejection is instant and free.

One thing changes at 1080p that nothing on the page mentions: the file came back as HEVC, where the 480p and 720p outputs were H.264. If you concatenate clips with stream copy, or serve them straight to a browser, a mixed-codec batch will bite. Check the codec on the file rather than assuming it from the model.

Duration is the other axis that changed between generations: 2.5 takes 4 to 30 seconds where the 2.0 line stops at 15, and a 30-second clip needs roughly ten beats of action in the prompt or the model will stretch one moment across ten seconds. We covered that pacing problem in the 2.5 prompting guide, and the 2.5 against 2.0 comparison has the rest of the capability deltas.

How Do You Compare Two Video Models Without Two Consoles?

The comparison in this post required exactly one thing that is annoying to arrange: running the same body against seedance-2.5 and seedance-2.0-mini with nothing else changed. Two model IDs, one key, one endpoint shape. Done natively, that is two provider consoles, two credit balances and two request schemas, at which point most people compare one model against their memory of another one and call it a benchmark.

Both models here answer on the same POST /v1/videos because the video endpoint is model-agnostic; the diff between the two runs in this article was the model field and nothing else. We used ofox’s video endpoint for it, and the same trick works on any gateway that keeps the request shape stable across vendors. The thing to check before trusting a cross-model comparison is that the gateway is not normalising fields on the way through: if aspect_ratio behaved identically on 2.5 and 2.0, that would be the smell. It did not, which is the evidence the field is reaching each model untouched.

References

• BytePlus ModelArk: Seedance 2.5 tutorial
• BytePlus ModelArk: Seedance 2.5 prompt guide
• ffmpeg: ffprobe documentation
• Pillow: ImageChops reference
• ofox: Create Video API
• ofox: Get Video Status API
• ofox model page: Seedance 2.5
• ofox model page: Seedance 2.0 Mini