Gemini Omni 1.1 Flash: Stable IDs, Extension Limits, and the Per-Second Math

Google's Omni line treats video as a multimodal conversation rather than a one-shot render. I spent a while going through the model card, the changelog, the pricing docs and the benchmark charts because the interesting question for anyone shipping this isn't "how good are the demos" — it's whether you can keep a usable take and steer it, instead of regenerating from scratch every time a detail is wrong.

Here's what's actually documented, and where the docs get slippery.

The spec sheet

The model card advertises native text, image, audio and video input, but individual API operations accept different combinations. Don't read the family-level multimodal claim as a guarantee that every endpoint takes every modality — check per-operation.

Three numbers get conflated constantly and they measure different things: the 3-second video reference (scene generation), the 10-second prior context (extension), and the 40-second cumulative extension chain. A 10-second output clip and a 40-second chain are not the same unit of work.

Two similar-looking model IDs, two different products

This is the part that will bite you in a migration script.

# Stable, paid Gemini Developer API MODEL=gemini-omni-1.1-flash # Gemini Enterprise Agent Platform, preview MODEL=gemini-omni-1.1-flash-preview # Legacy Gemini API endpoint, retiring 2026-09-30 MODEL=gemini-omni-flash-preview 

The retirement notice applies to gemini-omni-flash-preview. It does not refer to the gemini-omni-1.1-flash-preview endpoint currently exposed by Gemini Enterprise Agent Platform. Those are separate identifiers on separate surfaces, and I've already seen people conflate them in migration checklists. Verify the request shape and the returned output before you redirect production traffic.

What 1.1 actually adds

Longer continuation context. The model now reads up to 10 seconds of prior footage when extending — previous models were described as using the final second. Extensions chain in 10-second steps up to 40 seconds cumulative. This is not a 40-second text-to-video call; it's four appended segments. Check the joins, character identity and camera movement after every step, because drift compounds.

First-and-last-frame interpolation. Supply both endpoints and let the model generate the transition. Practical for product reveals, before/after sequences, and shots that need to cut cleanly into surrounding footage.

A real draft tier. Google reports up to 60% higher system throughput at 360p versus 720p, at roughly one third of the video-output cost. That's a throughput claim, not a per-request latency promise. The workflow I'd actually run: block composition and motion at 360p, iterate on prompt and references, approve a take, then pay for delivery resolution. Count the discarded attempts when you compare cost per accepted clip.

1080p and 4K via upscaling. Default output is 720p; the higher tiers are upscaled. Higher pixel counts don't remove motion or consistency errors.

Video as reference. In supported scene-generation workflows, up to 3 seconds of reference footage can carry timing, movement and character context that a still can't.

The pricing math, worked out

Token rates on the paid tier: $1.50 per million input tokens, $17.50 per million video-output tokens, $9 per million text-output tokens.

At 720p the billing is 5,792 video-output tokens per second. That gives:

OUT_RATE = 17.50 / 1_000_000 # USD per video-output token TOKENS_PER_SEC_720P = 5792 seconds = 10 cost = seconds * TOKENS_PER_SEC_720P * OUT_RATE print(f"{cost:.4f}") # 1.0136 -> the rounded $0.10/sec launch figure 

Which explains the rounded per-second numbers:

These are rounded Google launch estimates multiplied by generated duration. They exclude input tokens, text output, discarded attempts, and any separately billable processing — a 40-second extension chain can carry extra context cost and isn't a flat-price package. At these numbers, drafting at 4K costs about 10× per output second versus 360p.

One thing worth repeating: the per-second rate is provider-specific. If you route the same logical model through an aggregator, the billing is that route's, not Google's — a unified multi-model API like CometAPI can be a cheaper integration path, but the underlying model version behind the route is a separate question from the price tag.

Benchmarks are family-level, not 1.1-level

The official charts identify Gemini Omni Flash without isolating a 1.1 checkpoint. Treat this as family evidence, not a measured preview→1.1 delta. Elo values are relative ratings, not percentages.

Editing and instruction following are where the family is strongest. Fast motion and reference adherence go the other way — Seedance 2.0 leads both. You can have a model that's easier to direct without it being the right pick for action-heavy or reference-strict work.

On the image-to-video chart it's 1057 for Omni, 1054 for Grok Imagine Video, 1053 for Kling v3 Pro. Three points is not a decisive quality gap, and the published charts carry no confidence intervals.

Omni 1.1 Flash vs Veo 3.1 Fast

Pricing overlaps: tied at 720p ($0.10) and 4K ($0.30), while Veo 3.1 Fast is cheaper at 1080p ($0.12 vs $0.15). Omni's 360p tier exists for a different job — cheap iteration before you commit. Note that Veo's higher resolutions require 8-second generations and extension output is capped at 720p.

Where it breaks

Google still lists consistency, complex motion and text rendering as open limits. Longer extension chains are exactly where identity, geometry, lighting and stray objects drift, even when each individual clip looks fine. Upscaling to 4K doesn't repair any of that — inspect the scene before you treat a 4K file as a finished asset.

When I'd reach for it

If a usable take needs several rounds of direction — ad concepts, storyboards, product visualisation, short narrative — the combination of 360p drafts, keyframe endpoints and continuation is genuinely useful, because it converts "start over" into "targeted edit". If your current model already lands the clip reliably, measure the marginal value of the editing controls before you touch production traffic. And for highly dynamic action or strict reference fidelity, test the alternatives on those specific requirements rather than trusting an overall preference number.

The metric that matters isn't benchmark placement. It's accepted takes divided by total spend — retries, drafts and manual repair included.

Originally published at cometapi.com