Image, Audio, and Video Generation

Purpose and Scope

AI SDK Core treats media work as a sibling to text, object, tool, and embedding calls: the application selects a capable model, describes the task, and receives a typed result from the shared SDK surface. The supplied source gives the detailed public workflow for image generation through generateImage, including prompt input, model selection, binary accessors, sizing, multiple outputs, seeds, and provider options. This page uses that source-backed image workflow as the concrete model for thinking about broader media features such as transcription, speech, video generation, and file uploads. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

Media outputs are different from plain text responses because the result is usually an artifact that must be displayed, stored, uploaded, streamed, or converted at an application boundary. The image documentation makes that concrete by returning an image object with base64 and uint8Array accessors. Those access paths are not just convenience helpers; they represent two common integration styles. Base64 fits text-friendly transports and document formats, while byte arrays fit storage services, binary HTTP responses, and processing pipelines that expect raw bytes. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

Relevant Source Files

• content/docs/03-ai-sdk-core/35-image-generation.mdx - Documents the public generateImage workflow, image result accessors, size and aspect-ratio settings, multiple-image behavior, seed handling, and provider-specific image options.

Core Media Primitives

The central primitive documented in the supplied source is generateImage from the ai package. A call provides an image model and a natural-language prompt, then awaits a result containing either one generated image or a collection of generated images. This follows the larger AI SDK Core pattern: callers do not build provider-specific HTTP payloads directly for the common path; they express the desired operation through a stable SDK function and let the provider package translate model-specific details. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

import { generateImage } from 'ai';
 
const { image } = await generateImage({
  model: 'openai/gpt-image-1',
  prompt: 'Santa Claus driving a Cadillac',
});
 
const base64 = image.base64;
const bytes = image.uint8Array;

The neighboring media APIs should be understood as separate task primitives rather than as one generic media endpoint. Image generation creates images from prompts. Transcription turns audio into text. Speech generation turns text into audio. Video generation creates video artifacts, with the official reference naming an experimental video generation function. File uploads handle the handoff for providers or models that require file inputs. The shared design idea is still provider-agnostic orchestration: the application chooses a task, a model, and options, while model capability determines what is valid.

Image Generation Settings

The image documentation distinguishes size from aspectRatio because media models often expose fixed capability sets. A size is written as a width-by-height string, and an aspect ratio is written as a width-to-height relationship. The source is explicit that supported values differ by model and provider, so these settings should be treated as model configuration rather than purely visual preferences. A product may offer a friendly picker, but the backend still needs to constrain choices to the selected model. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

const square = await generateImage({
  model: 'openai/gpt-image-1',
  prompt: 'Santa Claus driving a Cadillac',
  size: '1024x1024',
});
 
const wide = await generateImage({
  model: 'openai/gpt-image-1',
  prompt: 'Santa Claus driving a Cadillac',
  aspectRatio: '16:9',
});

Multiple-image generation adds an execution detail that matters for latency, cost, and rate limits. The source states that generateImage can call the model as often as needed, in parallel, to produce the requested number of images. The SDK also manages each model’s internal per-call image limit by batching requests appropriately. Provider-documented defaults are used when available, and maxImagesPerCall lets callers override the batch size for new or custom models where the default is not optimal. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

const { images } = await generateImage({
  model: 'openai/gpt-image-1',
  prompt: 'Santa Claus driving a Cadillac',
  n: 10,
  maxImagesPerCall: 5,
});

Seeds are useful when an application wants reproducibility, but the source carefully ties determinism to model support. Passing seed controls the image generation process, and if the model supports it, the same seed always produces the same image. That conditional guarantee is important for tests, design workflows, and user-facing promises. The SDK can forward the option consistently, but it cannot make a provider deterministic if the underlying model does not honor the seed contract. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

Provider Options and Capability Boundaries

Media models frequently expose options that are too provider-specific to become universal SDK parameters. The documented escape hatch is providerOptions, where settings are nested under the provider key and become request body properties for that provider. In the OpenAI example, the application uses openai.image and supplies an OpenAI-specific image generation option such as style. This preserves a clean common API while still allowing teams to reach provider features when the model family supports them. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

import { generateImage } from 'ai';
import { openai, type OpenAIImageModelGenerationOptions } from '@ai-sdk/openai';
 
const { image } = await generateImage({
  model: openai.image('dall-e-3'),
  prompt: 'Santa Claus driving a Cadillac',
  size: '1024x1024',
  providerOptions: {
    openai: {
      style: 'vivid',
    } satisfies OpenAIImageModelGenerationOptions,
  },
});

The same capability-boundary mindset applies when extending beyond images. Audio transcription, generated speech, video, and file upload flows each depend on provider and model support for formats, durations, output types, and request options. Avoid designing a media feature as though every provider accepts the same inputs or returns the same artifact shape. Instead, choose the provider first, verify the model capability, keep common options in shared application code, and isolate provider-specific settings in configuration or provider-option layers.

Compact API Reference

Execution Flow

A typical image workflow starts by choosing a provider package or gateway model reference that supports image generation. The application then builds the prompt, decides whether to request a size or aspect ratio, and chooses whether a single output or several alternatives are needed. After the call resolves, the application reads either image or images, converts the result into the required transport form, and stores or renders the artifact. If provider-specific features are needed, they should be passed deliberately through providerOptions. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

For production systems, split responsibilities clearly. UI code can collect prompts, layout choices, and the desired number of outputs, but server code should validate those choices against the selected model’s supported capability set. Storage code should decide whether base64 or bytes are the canonical internal representation. Observability and tests should track request shape, batching choices, and artifact handling separately from visual quality. This separation keeps media generation maintainable even as teams add transcription, speech, uploads, or experimental video workflows.

Testing Signals and Next Steps

Tests should focus on the application contract that surrounds the SDK call. Verify that the intended model, prompt, size or aspect ratio, seed, requested count, batching override, and provider options are passed when expected. Also test how your code handles the single-result and multiple-result shapes, and how it converts base64 or byte data into storage, HTTP responses, or UI state. Avoid asserting that a seed is deterministic for every model, because the source explicitly makes that behavior dependent on provider support. Sources: content/docs/03-ai-sdk-core/35-image-generation.mdx

Next, read the provider and model documentation before committing to a media model, because multimodal support is uneven across providers and model families. Then use the Core function reference for exact entries such as generateImage, transcribe, generateSpeech, experimental video generation, and file upload APIs. If media artifacts appear inside chat experiences, continue to the UI stream and transport documentation so uploaded files, generated artifacts, message metadata, and custom data parts are represented consistently.