Seedance bitrate_mode standard or high: which models accept it

bitrate_mode is an optional Video Router field with two values, standard and high, and it applies to the Seedance 2.0 family (seedance-2, seedance-2-fast, seedance-2-mini). It does not apply to seedance-2.5, and Sume rejects it outright for Wan 3.0, MiniMax H3, MiniMax H3 Max and Gemini Omni Flash 1.1.

What the docs do not say is how much high changes the file or the bill. This post sticks to what the Sume repository and docs state, and shows a request that sets it safely.

Which models accept bitrate_mode?

The schema for POST /v1/video-router/generate accepts bitrate_mode as standard or high, then refuses it per model. Wan 3.0, minimax-h3 and minimax-h3-max return a validation error naming the field, and Gemini Omni Flash 1.1 does the same; its Video Router docs state there is no bitrate_mode. The Grok video model and the person-swap models also list it as unsupported.

For Seedance 2.5 the catalog constraint is simply no bitrate_mode, and the provider adapter drops the field instead of forwarding it. Treat that as unsupported and leave it out. For kling-3 the docs do not mention the field at all, so do not send it.

What does each value do?

The value names suggest high asks for a higher encode bitrate than standard, but Sume's docs do not define it further, publish file sizes, or state a price difference. Pricing for Seedance models is listed per 1,000 video tokens in GET /v1/videos/models and multiplied by 1.25 for billing, with no separate bitrate line.

So the honest test is empirical. Generate the same prompt twice, once per value, and compare the files with video inspect, which returns probe facts for a Sume-hosted clip without billing for probe and stills. Then check usage.cost on both jobs.

Where does it apply in the model family?

Summary of what the repository and docs state, per id.

How do I send it?

This request asks seedance-2-fast for a short 480p clip with bitrate_mode: high. It uses the cheap end of the range so a comparison costs little. Send the same body with standard and compare the two results.

import os, uuid, requests

body = {
    "model": "seedance-2-fast",
    "prompt": "A ceramic mug on a wooden desk, steam rising, soft window light",
    "resolution": "480p",
    "duration": 4,
    "bitrate_mode": "high",
    "mode": "async",
}
r = requests.post(
    "https://api.sume.com/v1/video-router/generate",
    json=body,
    headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}",
             "Idempotency-Key": str(uuid.uuid4())},
    timeout=60,
)
print(r.status_code, r.text[:300])

What should I do when my target is a platform bitrate spec?

If the goal is a minimum bitrate for an ad platform, bitrate_mode is not a bitrate setting and cannot promise a number; see TikTok in-feed ad minimum bitrate for the same point. Probe the finished clip, and if it misses the spec, re-encode outside Sume or choose a different delivery path.

Sume's video trim can conform resolution and frame rate on an exact cut, but it exposes no bitrate field either: the server compiles ffmpeg and rejects client codec and crf fields.

How should I test standard against high?

Fix every other input: same prompt, same resolution, same duration and the same model id. Submit both requests with different idempotency keys so you get two jobs, not one replay. When both complete, run video inspect with frames: false on each clip and compare the probe facts, then watch the two clips side by side.

Record the usage.cost of both jobs. If the numbers match, you have a local answer for your prompt and resolution, which is more reliable than any assumption. If they differ, write the difference into your own budget sheet and keep the evidence, because the public docs do not state it.