Gemini Omni 1.2 Flash Makes 15-Second Video Cheaper—Then Comes the Edit

A cheaper clip is only the opening bid

Google introduced Gemini Omni 1.2 Flash on November 5, putting a concrete offer in front of video product teams: native clips up to 15 seconds, conversational editing and a quoted price of $0.07 per second for 720p generation. Google says that rate is 30% below Omni 1.1. The release is generally available through the Gemini API and Google Cloud. Those are Google’s launch terms, rather than results from an independent production test. Google’s announcement

For teams reviewing models this week, the interesting question comes after the first attractive render. Can a customer change the background without losing a product’s shape? Can an approved performance survive a lighting adjustment? A video tool earns its place in a production workflow when revisions become predictable. Cheap generation helps, but an inexpensive clip that needs repeated rescue work can still be an expensive asset.

This release deserves a trial built around that distinction. Test the first generation, then keep working on it. A polished opening result tells you whether the model can make something appealing. The subsequent edits tell you whether your application can sell a useful service around it. The observations and evaluation proposals below are editorial analysis, not measured performance claims about Omni 1.2 Flash.

Put the rate on a usable-video budget

At the announced 720p rate, a 15-second generation works out to $1.05: fifteen multiplied by seven cents. That is a calculation from Google’s published rate, not a quote for a finished advertisement. It excludes any additional charges associated with your workflow, and it assumes that the quoted generation rate applies to the requested output. Confirm current billing details before turning that arithmetic into a customer promise.

The useful internal measure is total production spending divided by accepted deliverables. Include unsuccessful attempts, revisions and whatever processing your application adds. Keep human review visible alongside that spending. Otherwise, the model line item can look healthy while somebody spends the afternoon rejecting nearly identical clips with the same mangled product detail.

For a trial, give every job an acceptance rule before generating anything. A catalog clip might require the supplied item to retain its silhouette, material and visible markings throughout the shot. An explainer might require the visual sequence to match an approved script. Without a declared finish line, a team can quietly lower its standards until the economics appear to work.

Separate the model’s bill from your product’s margin. Storage, delivery, moderation, support and payment costs belong in the business calculation even when they do not appear on the generation invoice. The launch price makes experimentation easier to justify. It does not settle what to charge customers or whether unlimited revisions would be a sensible offer.

Fifteen seconds changes the brief

Google says users can choose durations from three to 15 seconds in one-second increments. It also describes stronger reference following and acknowledges remaining development work around fast sports action, rapid script changes and complex physics. That combination suggests a practical starting point: try a controlled product scene before handing the model a frantic action sequence. Launch details and limitations

A longer generation gives a creative team room for an opening image, a demonstration and a closing beat. It also creates more opportunities for a visual mistake to enter the shot. A convincing thumbnail cannot establish that a package remains accurate during a turn or that a hand behaves plausibly while handling it. Review the movement, including the unglamorous frames between the highlights.

Write a short shot brief with an explicit beginning and ending. Specify what must stay fixed, what moves and what the viewer should understand when the clip finishes. If the intended result is a product demonstration, the demonstration should determine the duration. Filling the maximum available length merely because the model allows it is an excellent way to manufacture extra review work.

Include an honest fallback in the product design. A customer whose request fails should be able to shorten the scene, simplify the action or return to an earlier version. Preserve the brief and references so that each retry answers a specific question. Randomly adding adjectives to a prompt is a poor substitute for diagnosing the failure.

The edit is where the product gets tested

Google DeepMind’s Omni product page describes a workflow in which successive natural-language edits develop an existing scene. It also presents image, video, text and audio references as inputs, alongside controls such as starting and ending frames. These are advertised capabilities; they do not establish how reliably a particular customer’s assets will survive a revision. Gemini Omni’s official product page

Use a revision brief that resembles an actual customer request. Start with an accepted product shot, change the environment, then change the lighting. After each edit, compare the output with the accepted version and the original references. Record whether the requested change happened and whether any previously correct detail moved with it. A beautiful new background does not compensate for a bottle that has quietly changed shape.

Keep those judgments separate. Instruction success asks whether the model performed the requested edit. Preservation asks whether it retained everything the customer expected to keep. Combining them into one aesthetic score can hide the failure that matters most commercially: the clip looks better, but the approved product is no longer the approved product.

Version history should be part of the application from the outset. Save the accepted parent, the edit instruction and the returned candidate. Let users branch from a previous version rather than forcing them to continue from the latest attempt. That makes experimentation recoverable and gives support staff something concrete to inspect when a customer reports that a small change broke a shot.

Treat Google’s comparisons as a test plan

DeepMind publishes side-by-side comparisons between Omni 1.2 and Omni 1.1. Its displayed text-to-video results put visual consistency at 62% versus 38%; its reference-to-video results show multi-reference identity consistency at 63% versus 37%. These are Google’s reported comparison results. They are not a forecast that the same share of your customers’ requests will pass review. Official performance charts

The categories are useful even without treating the percentages as your own forecast. Create separate review fields for visual consistency, reference identity and instruction adherence. A model can improve on one while a particular workload still exposes another. For example, attractive camera movement and faithful packaging are distinct requirements, and a product team should be able to see which one caused a rejection.

Use your own asset collection, including awkward material that sales demos tend to avoid: reflective surfaces, fine garment details, partially obscured products and references shot under inconsistent lighting. These are proposed evaluation cases, not documented Omni failures. Their purpose is to discover where your application needs stronger input guidance or a narrower promise.

Review candidates without revealing which version or prompt produced them when that is practical. Preserve rejection reasons in plain language. A note saying that the label changed during rotation is more actionable than a low overall score. Once the failure pattern is visible, you can decide whether to improve the reference pack, constrain the requested movement or keep that job outside the supported workflow.

Run the workflow before promising the speed

Google’s announcement emphasizes fast drafting and subsequent refinement, but it does not give a numerical latency guarantee for the service in that post. An application still needs its own timing measurements: submission to completion, completion to review, and review to an accepted deliverable. Customers experience that entire chain, including time spent deciding what to fix.

A useful trial should therefore exercise the interface as well as the model. Show job status, preserve requests across refreshes and make retries deliberate. If a user cannot tell whether a generation is still running, the interface invites duplicate submissions and confusing results. Model responsiveness cannot repair a product that loses track of its own work.

Use official imagery from the launch for announcement coverage where permissions allow, and label your own trial outputs as such. Provenance also belongs in the production design: DeepMind describes SynthID as technology for embedding and detecting digital watermarks in AI-generated content. That is a provenance mechanism, not a review of whether an advertisement accurately represents the item being sold. Google DeepMind’s SynthID overview

The decision for this week’s model review is concrete: can Omni 1.2 Flash carry a real brief through generation, revision and approval at an acceptable total cost? Put the launch claims beside observed results, keep the failed attempts in the accounting and make the acceptance criteria visible. The strongest reason to adopt the model would be a revision process your team can trust repeatedly. The cheapest first render is simply where that investigation starts.

Frequently asked questions

What does Gemini Omni 1.2 Flash cost?

Google quotes $0.07 per generated second at 720p. At that rate, a 15-second generation calculates to $1.05 before other applicable costs.

How long can its clips be?

The announcement specifies native generation and editing up to 15 seconds, with selectable durations from three to 15 seconds.

What should a team test first?

Generate a representative product shot, revise one detail and inspect whether the previously approved product, motion and framing survive.