Video 1.0 bitrate_mode: still in the shape, rejected by Auto

bitrate_mode is retained in Video 1.0's legacy request shape but Auto rejects it. Omit it, and note that Gemini Omni Flash 1.1 has no bitrate_mode either.

3 min readSume
All posts

bitrate_mode still appears in Video 1.0's request table, but Auto rejects it, so leave it out of new requests. The docs say the field is retained in the legacy shape.

What does the docs table say?

bitrate_mode is listed as optional: retained in the legacy shape; rejected by Auto. Together with routing_preset, which is ignored, it is one of the fields an older integration may still carry.

Which other fields behave differently on Auto?

These are the Video 1.0 fields whose behavior differs from what the name suggests.

Video 1.0 legacy fields, read 2026-09-30. Source: https://docs.sume.com/models/video
FieldBehavior on Auto
bitrate_modeRejected
routing_presetAccepted and ignored
generate_audioOmit; audio is always generated
resolution 4kRejected on this URL

Does any model have a bitrate mode?

The Video Router docs say gemini-omni-flash-1.1 has no bitrate_mode at all. Do not build a request around one.

How do I clean up an old request?

Remove bitrate_mode and resubmit with an Idempotency-Key. A replay of the same key returns the original job, so use a new key for the corrected body. See the Video 1.0 docs.

Where should I move new work?

New integrations should use POST /v1/videos. With sume/auto it uses the same Auto selection, and with a catalog id it runs a pinned family. Neither route lists a bitrate_mode field in its request table.

Billing is reserved on submit at provider list times 1.25, and the poll response reports usage.cost as the Sume billable amount. Sending an Idempotency-Key makes retries safe, because a replay returns the original job.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume