Vercel integrates Gemini Omni 1.2 Flash into AI Gateway to generate video via API

Vercel's AI Gateway now lists Gemini Omni 1.2 Flash, Google's video generation model, according to a changelog published by Vercel itself. The news isn't the model itself, but the channel: it can be called with google/gemini-omni-1.2-flash using the same API key that already authenticates other calls on the gateway, without opening a separate account on Google Cloud or Google AI Studio.

For front-end developers who already use Vercel's AI SDK for text, chat, or embeddings, this removes a well-known friction: managing two credentials, two billing dashboards, and two ways of measuring cost just because a video feature lives on a different provider than the rest of the product's AI stack.

How the call works in practice

Video generation uses the same generateText or streamText functions from the ai package, with providerOptions.google carrying the model-specific parameters. The changelog's example generates a three-second clip at 360p from a text prompt:

import { writeFile } from 'node:fs/promises';
import { generateText } from 'ai';

const { files } = await generateText({
  model: 'google/gemini-omni-1.2-flash',
  prompt: 'A red ball rolls across a white table.',
  providerOptions: {
    google: {
      responseModalities: ['text', 'video'],
      responseFormat: [
        { type: 'video', resolution: '360p', duration: '3s' },
      ],
    },
  },
});

const video = files.find(file => file.mediaType === 'video/mp4');
if (!video) throw new Error('No MP4 video returned');

await writeFile('video.mp4', video.uint8Array);

The video comes back inside the files array, filtered by mediaType equal to video/mp4. From there it's ordinary server code: write it to disk (as in the example), upload it to an object bucket, or return it directly as a binary response to the client. The model accepts resolution of 360p, 720p, 1080p, or 4K, in 16:9 or 9:16 format, which already covers both horizontal product video and vertical video for stories and reels.

streamText doesn't deliver video in chunks

A note on expectations is worth making here. Those who already use streamText for text are used to receiving token by token, updating the UI in real time. That doesn't happen with video: the changelog explicitly states that the file "is delivered as a complete file," even when passing through fullStream.

import { writeFile } from 'node:fs/promises';
import { streamText } from 'ai';

const result = streamText({
  model: 'google/gemini-omni-1.2-flash',
  prompt: 'A red ball rolls across a white table.',
  providerOptions: {
    google: {
      responseModalities: ['text', 'video'],
      responseFormat: [
        { type: 'video', resolution: '360p', duration: '3s' },
      ],
    },
  },
});

for await (const part of result.fullStream) {
  if (part.type === 'file' && part.file.mediaType === 'video/mp4') {
    await writeFile('video.mp4', part.file.uint8Array);
  } else if (part.type === 'error') {
    throw part.error;
  }
}

In practice, this means the UI can't show the video playing progressively while it's being generated. What you can do is use fullStream to react as soon as the file is ready, instead of being blocked waiting for a single Promise to resolve, which helps in flows with multiple outputs (text explaining the video and the video itself arriving through different parts of the stream), but it doesn't solve the latency of generating the clip.

Editing clips and chaining calls

Besides generating video from scratch, Gemini Omni 1.2 Flash edits source clips from 3 to 15 seconds long using up to six reference images to guide style or composition. It's also possible to extend an already generated video in increments of 3 to 10 seconds per call, up to a cap of 30 total seconds, reusing the context of the previous generation via previousInteractionId.

This chaining changes the way the application needs to be designed: generating a 30-second video isn't a single call, it's several, and the previousInteractionId from each response needs to be stored somewhere (database, cache, session) for the next call to reference. That's more state to manage than the stateless flow that people working with text calls are usually used to.

Pricing and what the AI Gateway handles underneath

According to Vercel, the AI Gateway reflects the provider's price with no markup and doesn't charge a platform fee on inference, including on requests that use your own key (BYOK). The gain from using the gateway instead of calling Google's API directly isn't a lower price: it's everything that comes along with the orchestration layer.

• Unified usage and cost tracking across multiple model providers, not just Google.
• Configurable retries, failover, and performance optimizations, with the promise of higher uptime than the standalone provider delivers.
• Custom reports, Zero Data Retention support, per-API-key budgets, and routing rules between models.

In short: those who already run their application on the AI Gateway get one more video model in the same billing and observability dashboard; those who don't use the gateway still pay the same Google price calling it directly, just without this management layer.

When it's not worth it

The cap of 30 total seconds per video, even with chained extensions, rules this model out for anything that requires longer video, such as a full ad or a larger narrative scene. For those cases, direct integration with Vertex AI, with access to more specific Google video parameters and models, may still make more sense than the AI SDK's abstraction.

It's also worth being cautious if the project doesn't use (or doesn't plan to use) the AI SDK or the rest of the Vercel ecosystem: adopting the AI Gateway just to gain this single video key introduces an infrastructure dependency that may not be worth the convenience gain, especially for teams that already have a mature Google credentials pipeline integrated with other parts of the product. And since video generation tends to take longer than a text response, anyone putting this call inside a serverless function needs to confirm the function's duration limit before assuming the full flow runs without a timeout.