Google Cuts Gemini Omni Video Generation Price by 30% — to $0.07 per Second

A fifteen-second clip for $1.05 is a clear starting point for a team adding video generation to its product. You can estimate the cost of a product card with animation, an ad variant, or a short how-to. But for the budget, a different number matters more: how many attempts it takes before the user agrees to accept the result.

Google introduced Gemini Omni 1.2 Flash and cut the price of 720p video generation to $0.07 per second. That is 30% less than the previous version. The maximum duration rose from 10 to 15 seconds, and the family received general availability status. These changes are confirmed by the Google announcement.

Count the finished clip

Imagine a service for small online stores. A seller uploads a product photo, describes the camera movement, and gets a short video for the catalog. For such a product, the lower rate is useful, but on its own it does not determine profitability.

At the stated price, one fifteen-second 720p generation costs $1.05. If ten full attempts are needed to pick a suitable result, the arithmetic gives $10.50. This is a calculation at the listed rate, without additional operations or your service's infrastructure.

Now a hypothetical scenario: a store needs one hundred accepted clips. With one attempt for each, the base cost is $105; with ten, it is $1,050. The difference comes from the workflow. So in a pilot, it is worth recording the number of attempts, the reasons for rejection, and the time spent manually reviewing each result.

A useful metric for a product manager is the cost of an accepted video. Alongside it you need the share of successful jobs and the time from request to download. Together they will show whether the feature supports your pricing and whether users are willing to wait. Separately, record which errors are fixed by a repeat request and which require human involvement.

Edits could change the economics

In the new version, Google also claims consistent clip editing through dialogue and improved reference following. For example, you can change the background or lighting of an already created scene. This is the vendor's description of capabilities; the material under review contains no independent quality assessment. Source: Google.

For a store, the practical question is simple: will the product stay the same after an edit? If the user asked for a different background and the shape of the packaging changed, the result will have to be checked again. Fixing one detail is useful only if it preserves the other important properties of the scene.

It is convenient to test this on your own set of tasks. Take products with small details, reflective surfaces, and prominent labeling. Give each the same sequence of changes. Then assess how many results can be used without manual rework. Such an experiment gives more grounds for choosing a model than a single successful demo clip.

The longer duration also needs checking. A longer scene can fit an extra action, but it also increases the amount of material that must be reviewed. For a short catalog movement, all fifteen seconds may be excessive. Choose the duration to fit the user's task.

What to check before launch

The headline of the original piece mentions an SLA. Google's announcement confirms general availability and the option to use Provisioned Throughput, but it gives no specific availability percentage or compensation terms. So it is too early to carry the word "SLA" into promises to customers without checking the contract. Google announcement.

Before integrating, check the terms of the chosen API, quotas, how edits are billed, and behavior during failures. In the interface, plan ahead for waiting, job retry, and a clear error status: your feature's customer experience depends on these details.

The practical next step is a small pilot on real requests. Compare the cost per accepted result, wait time, and amount of manual work. The 30% price cut is a reason to run such a test. The launch decision should be determined by its results.