gemini-omni-1.1-flash vs gemini-omni-flash-1.1: which id goes where
Google writes the model id gemini-omni-1.1-flash; Sume's catalog id is gemini-omni-flash-1.1. A mapping table, the old preview id, and how to avoid a typo.

Google's Gemini API names the model gemini-omni-1.1-flash; Sume's video catalog calls the same Omni Flash 1.1 model gemini-omni-flash-1.1. The word order differs, so an id copied from Google's docs into a Sume request will not match, and the reverse is also true. Each id works only against its own API.
Google's ids come from its deprecations page and changelog, read 2026-10-01. Sume's id comes from the Video Generation and Video Router docs.
What are the ids on each side?
Google's changelog says Gemini Omni Flash became generally available on August 27, 2026 as gemini-omni-1.1-flash, and that the earlier gemini-omni-flash-preview endpoint is deprecated on September 30, 2026. That preview id is already past its date. Sume lists a single Omni id and no preview id to track.
| Where | Id | Status |
|---|---|---|
| Gemini API | gemini-omni-1.1-flash | GA August 27, 2026; no shutdown date announced |
| Gemini API | gemini-omni-flash-preview | Deprecated September 30, 2026 |
Sume /v1/videos and Video Router | gemini-omni-flash-1.1 | Listed in the catalog |
Sume sume/auto | sume/auto | Echoed back; the family that ran is not disclosed |
How do I avoid using the wrong id?
Do not type the id from memory. Read it from the catalog at startup and fail loudly if it is missing. Sume's own troubleshooting advice for a model-not-found error is to verify the id against the Video Models API, because Sume uses bare catalog ids rather than org/slug forms.
import os, requests
r = requests.get(
"https://api.sume.com/v1/videos/models",
headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"},
timeout=30,
)
r.raise_for_status()
ids = {m["id"] for m in r.json()["data"]}
wanted = "gemini-omni-flash-1.1"
if wanted not in ids:
raise SystemExit(f"{wanted} is not in the catalog: {sorted(ids)}")
print("ok", wanted)Where does the Sume id appear?
Everywhere you name a model. On POST /v1/videos it is the model field. On the older POST /v1/video-router/generate it is the same string, because the two surfaces share one catalog. Over hosted MCP, generate_video takes the id in payload.model, and omitting it routes to sume/auto; the catalog ids come from the video-router_models tool.
The poll response echoes the id you sent, which makes it a good field to store next to every finished clip. If a vendor retires or renames a model later, that stored id tells you which jobs need a re-run, instead of leaving you to guess from a prompt.
What if I do not care which model runs?
Send sume/auto. Sume's docs describe Auto as 3 to 10 second clips at 16:9 or 9:16, with 720p and 8 seconds as the create defaults. The response reports sume/auto and Sume does not disclose which family served the request, so you cannot log the resolved model; if you need a record of exactly which model produced a shot, pin the id above.
Limit: this post covers naming only. It makes no claim that outputs are identical between Google's endpoint and Sume's.
Sources
Related posts
More in Models
- Gemini Omni audio reference: unsupported; Sume models that take audio
Google says Omni's API doesn't accept uploaded audio references. Sume's Omni row has no reference_audio_urls; Seedance 2.x, Wan 3.0 and MiniMax H3 honor audio.
- Gemini Omni extend: no new dialogue on an uploaded talking clip
Google says you can't extend an uploaded Omni clip where someone talks to add dialogue; extension only appends, to clips up to 10 s. Sume lists no extend mode.
- Gemini Omni with several videos: 3 references, no cross-video use
Gemini Omni takes up to 3 reference clips of 3 s each, yet Google warns that reasoning across several videos may degrade output. Sume: one video_url source.
- Gemini Omni REST: output_video is SDK-only, read the steps array
Calling Gemini Omni over REST? interaction.output_video is SDK-only. Read the base64 video from the model_output step; on Sume you get a media URL instead.
Written by Sume