As of May 12, 2026, Google had not published a public developer contract for "Gemini Omni API": no model ID, no endpoint reference, no pricing row, and no changelog entry in the checked first-party developer docs. Treat the phrase as a surfaced Omni label until Google adds a callable model or API page.
| If your job is... | Use now | Do not assume |
|---|---|---|
| Generate video clips or marketing visuals | Veo 3.1 through the Gemini API video route | That a rumored Omni name replaces Veo |
| Build realtime voice or video agents | Gemini Live API with gemini-3.1-flash-live-preview | That Live API is an offline video generator |
| Build text, image, or tool-using multimodal apps | A currently listed Gemini API model | That gemini-omni is a valid model string |
| You specifically need Omni | Wait for a first-party model ID, endpoint docs, pricing note, and release note | That leaks or provider catalogs are enough for production |
Stop rule: do not put gemini-omni, omni, or any provider-specific Omni alias into production config until official Google developer docs publish the model ID and reference. Leak reports, app UI strings, social posts, and provider catalog entries can tell you what to watch, not what to call.
The current public status
Last checked on May 12, 2026, Google's public Gemini API model list did not expose an Omni model. The same check found no Omni entry in the public Gemini API release notes, no Omni pricing row on the Gemini API pricing page, and no Omni-specific endpoint reference in the public API reference pages.
That is enough to answer the developer question. A callable Google API needs a model identifier, a documented request surface, and a billing or availability boundary. Without those, there is nothing stable to put in a production config, SDK wrapper, provider router, cost calculator, or customer-facing roadmap.
The nearest official routes are visible and separate:
| Developer job | Official route today | Why it is not Omni |
|---|---|---|
| Video generation | Veo 3.1 on the Gemini API paid tier, including veo-3.1-generate-preview, veo-3.1-fast-generate-preview, and veo-3.1-lite-generate-preview | It is the documented Veo route, not an Omni model ID |
| Realtime voice or video agents | Gemini Live API with gemini-3.1-flash-live-preview | It is a stateful Live API model for realtime interaction, not an offline video model |
| General multimodal reasoning | Current listed Gemini API models | The selected model should come from the official model list, not a leaked label |
| Future Omni-specific work | Watch first-party docs and release notes | The proof threshold has not been met yet |
For Live API implementation details, use the existing Gemini 3.1 Flash Live API guide. For quota and billing orientation, use Gemini API free tier. For video-model tradeoffs, use Seedance 2 vs Veo 3 vs Sora 2 as the broader comparison branch.
What the Omni leak can and cannot prove
The surfaced Omni label matters because it looks connected to Google's Gemini app and video workflow. TestingCatalog reported a Gemini interface/model-card appearance around May 11, 2026, with language about a new video model, remixing videos, editing in chat, and templates. WindowsReport also framed the signal as a Gemini app leak tied to video generation and editing. WaveSpeed's earlier write-up treated the signal as a UI string or video-tab indicator ahead of Google I/O 2026.
Those reports are useful for one narrow reason: they explain why builders are asking about Omni now. They do not create a developer API contract.
Use this evidence ladder:
| Source class | What it can prove | What it cannot prove |
|---|---|---|
| First-party Google developer docs | Model ID, endpoint, SDK path, supported modalities, billing status, preview or GA state | Future plans that are not written there |
| Google release notes or pricing rows | Availability changes, model-list additions, cost boundary | App UI experiments before docs change |
| App UI leaks and screenshots | A label may be in testing or staged rollout | That a public API exists |
| Reddit, YouTube, X, blogs, provider catalogs | Market attention and possible early signals | Official model IDs, pricing, endpoint behavior, SLA, or production safety |
That separation is not pedantry. A leaked app label could become a Veo wrapper, a Gemini-native video model, a multimodal creative mode, an agent feature, or a name that never ships publicly. Each path implies different code, cost, permissions, and user expectations.
Choose the official route by the job
The safest way to decide is to split the job, not the rumor.
Use Veo 3.1 when the task is video generation, editing, or creative clip production. Google's pricing page lists the current Veo 3.1 preview model IDs and describes the model family as available to developers on the paid Gemini API tier. That gives you a documented video route today, even if it is not the same thing as Omni.
Use Gemini Live API when the task is realtime voice or video interaction. Google's Live API overview describes a stateful WebSocket surface for low-latency voice and vision interactions. The current Gemini 3.1 Flash Live model page lists gemini-3.1-flash-live-preview as the model code, with text, image, audio, and video inputs plus text and audio outputs. That is the route for voice agents, live assistants, and interactive media sessions.
Use current Gemini API models when the task is standard multimodal reasoning, tool use, structured output, retrieval, or app logic. The model should come from the official model list and the capability page for the feature you need. Do not invent gemini-omni as a shortcut.
Wait when the requirement is specifically Omni. Waiting is not passive. It means you keep the integration swappable, record the model IDs you actually use, and define the exact evidence needed before you rename anything in production.
The proof threshold for a real Omni API
If Google announces Omni at I/O 2026 or later, the developer proof threshold is still concrete. Do not ship on a keynote name alone.
| Required proof | Why it matters |
|---|---|
| Model ID in the official model list | Without it, SDK calls and provider routing cannot be stable |
| Endpoint or API reference page | Without it, request and response shape are undefined |
| Pricing row or billing note | Without it, cost estimates and customer promises are guesses |
| SDK, cookbook, or official example | Without it, sample code may be reverse-engineered or provider-specific |
| Quota, region, and preview or GA status | Without it, production capacity and compliance cannot be assessed |
| Release note or changelog entry | Without it, teams cannot tell whether the change is public, previewed, deprecated, or rolling back |
Google I/O 2026 is scheduled for May 19-20, with the Google keynote listed for May 19. That makes the timing worth watching, but it does not change the rule. Re-check after the event, then decide from the developer docs, not from recycled screenshots.
How to keep an app ready without betting on a rumor
Build the abstraction around job and capability, not around the rumored name.
For video generation, name the internal capability video_generation and map it to veo-3.1-generate-preview, veo-3.1-fast-generate-preview, or veo-3.1-lite-generate-preview according to your quality and latency target. For realtime agents, name the capability realtime_voice_video and map it to gemini-3.1-flash-live-preview. For general multimodal work, choose a listed Gemini model and store the exact model ID in config.
Then add a future switch:
| Config concern | Safer pattern |
|---|---|
| Model name | Store official model IDs only |
| Capability | Use stable internal capability names such as video_generation or realtime_agent |
| Provider claim | Record provider, route, model string, and source date separately |
| Cost | Tie estimates to official pricing rows or your own measured provider invoices |
| Rollback | Keep old route and new route side by side until outputs, cost, latency, and safety pass |
This gives you a clean migration path if Omni becomes real. If Google publishes an official Omni model ID, you add it as a new route and test it. If Omni remains an app-only or consumer-facing label, your developer stack keeps shipping on documented APIs.
Provider claims need a second boundary
Some gateways and model catalogs may list future or unofficial labels before first-party docs do. That can be useful for experimentation, but it should be labeled as provider-specific access, not official Google API availability.
Ask four questions before testing any provider-side Omni entry:
| Question | Why it matters |
|---|---|
| What exact model string did the provider expose? | It may not match any Google model ID |
| Which upstream owns the request? | Logs, billing, support, and safety policy follow the actual route |
| What does the provider charge and guarantee today? | Provider pricing is not official Google pricing |
| Can you reproduce the same output through first-party Google docs? | If not, treat it as a provider experiment, not a portable integration |
Do not market provider access as "Gemini Omni API" unless Google publishes the underlying developer contract. A provider can be a useful route, but it cannot change what Google has or has not documented.
FAQ
Is Gemini Omni API available now?
No public Google developer contract was available in the checked first-party docs as of May 12, 2026. There was no public Omni model ID, endpoint reference, pricing row, or release-note entry.
What is the Gemini Omni API model ID?
There is no official public model ID to use yet. Do not use gemini-omni in production config unless Google publishes that exact or equivalent model string in the official model list or API docs.
Is Gemini Omni the same as Veo 3.1?
Not based on public developer docs. Veo 3.1 is the documented Gemini API route for video generation today. Omni is a surfaced label from app/UI and news signals, not a documented replacement for Veo.
Should I use Gemini Live API instead?
Use Gemini Live API if the job is realtime voice or video interaction, such as voice agents, assistants, or live multimodal sessions. Use the documented model gemini-3.1-flash-live-preview. Do not use Live API just because you are trying to approximate a rumored video-generation model.
Can a third-party provider offer Omni before Google documents it?
A provider can expose a provider-specific route or label, but that does not make it an official Google developer API. Treat it as an experiment unless the provider can show the exact upstream, model string, billing boundary, and support path.
When should I re-check?
Re-check after Google I/O 2026 on May 19-20, after any Gemini API model-list update, and before every production decision that depends on Omni. The minimum evidence remains the same: model ID, endpoint docs, pricing or billing note, SDK example, quota/status boundary, and release note.