Synthetic video for robot and driving tests: Seedance 2.5 API

Seedance 2.5 can generate synthetic video, and ByteDance names robot training and driving tests as targets, but an API call gives you an MP4, not a labelled dataset. The launch post says the model can generate synthetic video data to help train robots' perception and manipulation, support industrial simulations and equipment demonstrations, and simulate long-tail driving scenarios such as extreme weather and complex traffic. On Sume you can submit seedance-2.5 jobs of 4 to 30 seconds in bulk; labels, scene metadata and any physical-accuracy check are your job.

What does ByteDance actually claim?

Read from the Seedance 2.5 launch post on 2026-10-03: the model is being used in industrial manufacturing, embodied intelligence and autonomous driving workflows. It lists synthetic video for robot perception and manipulation, industrial simulation and process training, and simulated long-tail driving cases for test samples.

The same post is candid that physical plausibility of complex motions and stability in multi-subject interaction are still open. That is the central risk for a training set: a clip can look right and be physically wrong.

What does a Sume job give you?

The Video generation doc describes the flow: submit to POST /v1/videos, get a job and a polling URL, poll until completed, then download from the content URL. The poll response carries usage.cost, the Sume billable amount. Completed jobs list artifacts on media.sume.com (Jobs and results).

Two behaviours matter for a dataset. First, no v1 model accepts seed, so you cannot regenerate the same clip; keep the prompt, the request body and the output together. Second, sume/auto hides which model served a request, so pin seedance-2.5 when the source model must be recorded.

How do you run many scenarios safely?

Give every scenario its own Idempotency-Key, so a retry returns the original job rather than a second charge. Generation admission explains that submits beyond your concurrency limit are accepted as queued until the queue is full, then fail with 429 queue_full. Use the generation_limits the API reports instead of a hard-coded number.

Run a small pilot at 480p, review every clip against the scenario sheet, and only then scale. A scenario that fails the physical check is a prompt problem to fix, not a clip to keep.

How do you check each clip before it enters a set?

Video inspect reads one Sume-hosted clip and returns probe facts (such as duration and whether it has audio) plus sampled stills. With no frames field it returns eight mid-bin stills; you can ask for explicit timestamps (1 to 24 values) or an fps up to 2. Source clips up to 1,800 seconds are accepted, which covers a 30-second Seedance clip many times over.

A short review loop works well: inspect the clip, look at the stills where objects touch or move fastest, and reject any clip where an object passes through another, changes shape or vanishes. Log the verdict next to the stored request body. That log is the part of the dataset no video API can give you.

Is this cheap enough to try?

You pay per request from your workspace balance: the amount is reserved at submit at the provider list price times 1.25 and the poll response reports usage.cost. Start with a dozen 480p, 4 to 8 second clips of one scenario, review them, then decide whether longer 30-second clips add anything your use needs. Long clips raise the cost and also give a physical error more time to appear.

What is not covered?

Sume's docs describe generation, jobs, billing and downstream media tools. They do not describe dataset labelling, simulation fidelity or a guarantee that generated footage is physically correct. Treat the output as candidate footage and validate it before it trains or tests anything.