Gemini Omni 1.2 Flash: 15-Second AI Video for Less

Longer clips, but still short-form output

Gemini Omni 1.2 Flash can generate a clip of up to 15 seconds in one go. The previous cap was 10 seconds.

That's a noticeable bump for short product demos, social cutaways, or a quick establishing shot. It can also reduce the number of separate generations you need when a concept needs a little more runway.

Still, 15 seconds isn't long-form production. You'll likely keep planning sequences as separate shots and stitching them together, or running multiple generations for different beats. And when you join clips, you'll still need to check continuity instead of assuming a longer generation automatically makes the whole sequence behave.

More consistency across details

Google says the model does better at keeping faces, clothing, packaging text, and brand colours consistent across camera angles - fewer glitches, fewer jump cuts. In Google DeepMind comparisons, testers preferred version 1.2 over 1.1 for visual consistency 62% of the time.

That's encouraging, but it's not a guarantee. It's a preference result from Google's comparisons, not proof that every logo, face, or product label will come out identically every time. Teams should still review generated footage carefully - especially when small errors (an incorrect label or a mismatched product appearance) can mislead customers or force you back into rework.

Availability across Google's products

The model is rolling out in Flow, Google Vids, Google Ads, and the Gemini app for Google AI Ultra subscribers. Businesses can also use it through Google Cloud. Google says this is the first time Omni has been generally available through Cloud, which matters if you're trying to plug it into a business workflow instead of relying only on a consumer app.

In other words, this isn't just more capability - it's easier access. But access alone doesn't tell you whether the output quality, review process, and total cost fit what you actually need to ship.

Calculate the base cost before estimating savings

At $0.07 per second, a 15-second clip costs about $1.05 to generate via the API ($0.07 × 15). At $0.10 per second, the same duration would be $1.50. That's a $0.45 difference per clip at that length.

That math is a starting point, not a full production estimate. It assumes a single generation and uses the announced 720p rate. If you try multiple alternatives, throw some away, or do additional edits, total spend goes up. Also, the announcement doesn't spell out exactly how every editing turn is billed - so before you forecast heavy usage, check the pricing details for your specific product and integration.

A simple planning model looks like this:

• Base generation cost: clip duration multiplied by the per-second rate.
• Iteration allowance: expected number of attempts multiplied by the base generation cost.
• Review and finishing effort: the time people spend checking, correcting, and incorporating the output.

For example, planning ten 15-second concepts shouldn't mean budgeting for only ten finished clips if you expect to test several versions per concept. Your cost per approved asset depends on how many attempts it takes to get something acceptable.

A lower unit price does not automatically lower total cost

A cheaper generation can justify more experimentation. That can be worth it if it helps you find a better concept faster. It can also backfire: you may generate more variations, then spend the same (or more) time reviewing and fixing them.

The real question is whether the model replaces expensive work, removes a bottleneck, or lets you test ideas you couldn't previously afford to try. To keep the comparison honest, track cost per approved asset - not cost per generated second. Include attempts, acceptance rate, and human review time. That's the metric you'll care about when you compare against a conventional shoot, a motion graphics workflow, or a prior AI model.

Use iteration to isolate the change

A practical workflow is to build a viable base clip first, then change one meaningful variable at a time. If the product scene is close but the background is wrong, request a background change without also rewriting camera angle, lighting, and product appearance.

Focused edits make it easier to tell whether the requested change worked - and they reduce the "was it the prompt or the model?" uncertainty when something breaks.

That said, it's still not guaranteed that the model preserves every untouched element. The announcement says users can edit over several turns, but it doesn't promise pixel-level control. Every result should be checked against the original brief. If a supposedly local change ends up affecting the product, framing, or brand colours, you'll probably need to retry with a simpler instruction or shift to a different production method.

Treat the model as part of a review loop

For business use, you still need a clear approval step. One workable sequence looks like this:

1. Define intended use, audience, and required visual details.
2. Generate a base clip and check whether the core idea is usable.
3. Make targeted chat-based edits, changing one priority at a time.
4. Review for visual continuity, text, branding, and factual accuracy.
5. Approve, revise again, or move the shot to another production method.

This helps avoid a common trap: treating the first polished-looking output as "close enough." Visual plausibility isn't the same thing as accuracy. A product label, a person's appearance, or a brand colour can be wrong even when the clip feels convincing at a glance.

Where it could help teams

Short-form marketing and concept work are natural fits, because they often involve multiple versions of a relatively small visual idea. A team might test different backgrounds for an ad concept or try how a product looks in different scenes before committing to a more expensive production path. Google's rollout in Google Ads and Google Vids also brings the model closer to existing content workflows for some users.

The real test is whether chat-based revisions reduce time and cost to reach an approved asset. If the workflow mainly makes it easier to generate more variations that still need substantial correction, you won't save much. Measure approval rate and time to final output - not just how many clips you produced.

Compare it against the actual task

Google's 15-second maximum is an improvement over 10 seconds. It's still shorter than the 30-second clips attributed in the announcement to ByteDance's Seedance 2.5, unveiled in June.

But duration alone doesn't tell you which model is more useful. The better comparison looks at output quality and consistency, control over revisions, access, price, and how much finishing work each option requires.

Don't just test the "best looking" demo. Run the same kind of brief across tools, with the same target duration and acceptance criteria. Include details that matter in your real work - packaging text, a recurring person, a specific colour palette. Then compare accepted results and total effort, not only the most impressive output from each model.

Keep known limitations in the production plan

Google says it's still working on fast sports action, quick script changes, and complex physics. Those are meaningful boundaries. Rapid motion can make errors more noticeable. Script changes can force timing and scene content to shift in ways that don't match what you intended. Complex interactions are also where "plausible-looking" can drift away from what you actually need to represent.

That doesn't make it useless for movement or dialogue scenes. It just means you should plan more testing, stricter review, and clear "stop conditions" when a generation doesn't meet your requirements. If the brief depends on precise action, choreography, cause and effect, or exact spoken content, you should assume there's a chance the output won't get it right.

Make the decision on repeatability

One ranking referenced in the announcement puts nine Chinese models in the top ten, with Google as the only US company represented. That's a snapshot of a competitive landscape, not a reason by itself to pick or reject a model.

Rankings can help you find candidates - but they don't measure fit for your team's production workflow. A practical evaluation should answer four questions:

• Can the model produce the required shots and details often enough to be useful?
• How many revisions does it take to get an approved result?
• Does its price stay attractive once you include retries and review time?
• Can your team access and manage it through a workflow that matches your operations?

If it passes those tests on real briefs, a pilot makes sense. If it only looks strong in easy demonstrations, a lower per-second price won't be enough to make it dependable as a production dependency.