Reference limits per request, vendor vs Sume: Wan 3.0, Seedance, Omni

The vendors' published caps per request are higher than what Sume's catalog allows in some cases, and Sume does not run every model. Alibaba says Wan 3.0 takes up to 20 reference assets; Sume's wan-3.0 entry allows up to 10 images, 5 videos and 5 audio files. ByteDance says Seedance 2.5 takes up to 30 images, 10 video clips and 10 audio clips per pass. Google says Gemini Omni 1.1 Flash takes video references of up to 3 seconds. Luma says Ray3.2 takes up to 16 keyframes, and Sume does not ship Ray3.2. The table below puts the vendor line and the Sume line side by side, so you can plan a request that the platform you actually call will accept.

The table

Vendor numbers come from each vendor's own page, read on 2026-10-05. Sume numbers come from the Video generation docs and the Video Router docs, and from the catalog constraints you can read through GET /v1/video-router/models.

What the gap means

The gap has three causes. Vendors state what the model can do in their own product, and Sume exposes the fields it has wired up and tested. A vendor can accept documents and webpages as reference types, while Sume's request takes URLs for images, video and audio only. And some vendor features are not request fields at all but behaviors, such as Wan 3.0's automatic scene splitting.

• If you need more than 10 images for Wan 3.0 on Sume, split the job into two requests and join the clips with Timeline 1.0.
• If you need document input, prepare the pages as images and send those; do not expect Sume to read a PDF.
• If you need Ray3.2 keyframes, you need Luma's own surface; Sume's catalog does not list the model.
• If a number matters, read it from the catalog at call time, not from a table in a blog post.

How to read the live limits

Two reads cover it. GET /v1/videos/models returns, for each model, supported_resolutions, supported_aspect_ratios, supported_durations, supported_input_references and pricing_skus. GET /v1/video-router/models returns capabilities and notes that each model can have a different envelope. Write your request builder to read these two responses rather than hard-code a limit, because the docs say limits differ for each model and Sume can change a catalog entry.

curl "https://api.sume.com/v1/videos/models" \
  -H "Authorization: Bearer $SUME_API_KEY"

curl "https://api.sume.com/v1/video-router/models/wan-3.0" \
  -H "Authorization: Bearer $SUME_API_KEY"

A note on availability

Vendor availability differs from Sume availability. ByteDance's Seedance 2.5 page says the API is coming via BytePlus ModelArk, while the model is already in Sume's catalog. Treat each vendor page as a statement about that vendor's product on the date read, and the Sume docs as a statement about Sume. When they disagree, the one you call is the one that decides what your request can contain.