On August 27, Google moved Gemini Omni 1.1 Flash, its video generation model, to general availability under the stable ID gemini-omni-1.1-flash. In the same move, the old gemini-omni-flash-preview endpoint was scheduled for deprecation on September 30. Do the math: roughly thirty days to migrate, retest, and ship. I don't use that model — the haircut preview in Miraviso works on images, not video — but the pattern is exactly the risk anyone lives with once a hosted model sits inside their product. And in my case there's an extra twist worth writing down: a privacy-first architecture takes away precisely the tool you'd want for managing the migration.
The pattern: GA is good news with a deadline inside
The sequence is familiar by now: a model ships as a preview, you integrate it because it's the only way to get that capability, the product grows to depend on it, and one day GA arrives — good news — bundled with a shutdown date for the preview, which is a deadline on your calendar set by somebody else. The Omni transition has all the typical details, too: a separate channel ID on Vertex AI (gemini-omni-1.1-flash-preview, which is not the stable Gemini API ID despite the nearly identical name), new controls the preview never had, and — according to third-party reports I've read, worth verifying against the official pricing pages — no clearly published GA price at announcement time. Migrating is not swapping a string: it's retesting quality, latency, and cost with your inputs, because the release notes won't do that for you.
Thirty days is tight if you learn about the migration from the deprecation email. It's comfortable if, the day the email lands, all you have to do is run a procedure that already exists. That's the entire difference.
My case: half the product is immune, half is not
Miraviso has two deliberately different technical paths, and this story lights both of them up. The color try-on runs entirely on the salon's tablet with on-device MediaPipe: the video never leaves the device. That path is structurally immune to endpoint deprecations — the model ships with the app, and nobody can switch it off remotely. It's an under-discussed benefit of going on-device: not just privacy and latency, but independence from someone else's release calendar.
The haircut preview, on the other hand, is generated server-side in the EU, with Gemini on Vertex AI, after the client's consent. There the dependency is real, and it's the price of a capability you can't get on-device today. That path lives on Google's calendar, and has to be designed with that in mind.
The twist: you can't regression-test data you don't keep
The standard way to handle a model swap is a regression corpus: sample real production inputs, replay them against the new model, compare outputs. Well — I can't. By design, not by accident: preview images are never written to disk. They pass through, get processed, return to the tablet, gone. It's one of the promises the product stands on, and it doesn't become negotiable just because it would be convenient.
The consequence is that the test corpus has to be built outside production traffic, and in advance. Concretely, that means three things:
- An explicit, consented golden set: images collected specifically for testing — your own, volunteers who signed up for that exact purpose, or datasets with a suitable license — covering the cases that actually matter: hair types, skin tones, real salon lighting, crooked framing. It's not a poor substitute for production data: it's the only corpus you have, so its quality is the ceiling on the quality of your tests.
- The model behind a hard boundary: one place in the code that knows which model is called and how. If the endpoint name shows up in multiple files, scattered environment variables, or stored job templates, then step one of any migration — finding every occurrence — is already an afternoon-long project.
- Evaluation criteria that don't require the originals: if you compare old vs. new by eye on the golden set, fine — but the criteria for what makes a preview "acceptable" must be written down beforehand, because aesthetic judgment under mid-migration pressure is the worst judgment you will ever exercise.
The deadline is the product working as intended
There's a lazy reading of news like this: "big tech keeps killing your APIs, what a disaster." I don't share it. A vendor that moves a model to GA and retires the preview is doing serious catalog maintenance; the alternative — eternal previews nobody promises to maintain — is worse. The deprecation isn't the problem. The problem is arriving at it with no golden set, no boundary around the model, and the endpoint ID copy-pasted into four places.
The rule I hold myself to is trivial to state: every capability bought from a hosted model must have, from day one, an answer to the question "how do I replace this?". Not a detailed plan — an answer. If the answer is "I don't know", that's not a dependency, it's a lien on the product. And much like the data that ends up in your logs without anyone deciding it should, the right time to think about it is while the architecture is still fresh — not when the email with the date inside arrives.