Seedance 2.5 reference-to-video: what Sume accepts per pass

What can you feed Seedance 2.5 as references? ByteDance's announcement says up to 30 images, 10 video clips and 10 audio clips per pass, covering clay renders, motion, creative and scene references. Sume's seedance-2.5 row accepts image, video and audio reference types through input_references; it does not label them as clay or motion, they are plain references your prompt explains.

Vendor list vs Sume field

The Seed announcement names the reference kinds as use cases. Sume's docs define a reference by media type, and a model accepts one only if its supported_input_references includes it.

Writing the prompt

Because roles are not fields, say what each reference is for: for example, "use the first video only for camera motion and the image for the room." Order matters less than clarity, so name each reference in the prompt.

Sume's Seedance 2.5 clips run 4 to 30 seconds at 480p, 720p and 1080p, with native audio. Billing is list price times 1.25, rounded up to cents, from a per-1,000-video-token rate.

Limits to check

I did not read per-type reference counts for Sume's seedance-2.5 row, so treat the vendor's 30, 10 and 10 as the vendor's limits, not a promise about Sume's. Expect a 400 error if a row does not accept a reference type. Submit a small request with one of each type before you plan a job that depends on high counts.

What the Seed page also says

Beyond references, the announcement lists timestamp-level editing, green-screen background replacement, camera perspective editing and reference-based editing. Those are model capabilities described by the vendor. Whether a given edit works through Sume depends on what the request fields expose, and edit modes are covered in a separate post on timestamp editing. For plain generation with references, the request needs only a prompt, a resolution, a duration and the reference entries.

A last point on the counts. The vendor figures are per generation pass, and a pass is not the same as a request on any particular reseller. Treat them as an upper bound on what the model can ingest, and expect the API you call to apply its own, possibly lower, caps. When Sume lists a cap in its catalog, that catalog value governs your request.