Understanding t2iModels and i2iModels: Text-to-Image vs Image-to-Image in models.js

The t2iModels array stores Text-to-Image models that generate images from textual prompts alone, while i2iModels stores Image-to-Image models that require a source image through a defined imageField and optionally accept prompts for transformation.

The Anil-matcha/Open-Generative-AI repository organizes generative AI model metadata in src/lib/models.js, where the distinction between t2iModels and i2iModels determines how the application constructs API requests and renders user interfaces. These two exported arrays define fundamentally different model contracts: one for text-only generation workflows and another for image transformation pipelines. Understanding this architectural split is essential for correctly implementing model calls in src/lib/muapi.js and extending the platform with new providers.

Core Differences Between t2iModels and i2iModels

The repository maintains two separate arrays to distinguish between models that create images from scratch versus those that modify existing images. This separation drives both the API payload structure and the frontend component rendering logic throughout the application.

Text-to-Image (T2I) Model Characteristics

t2iModels contains metadata for models that generate images from a textual prompt without requiring a source image. According to the source code in src/lib/models.js, these entries define the following schema characteristics:

• A prompt input field for the text description.
• Optional size-related fields such as width, height, or aspect_ratio.
• No required source image field.
• Typically accessed via the getT2IModelById helper function.

The Nano Banana model (nano-banana) exemplifies a pure T2I implementation that only requires a prompt and accepts an optional aspect ratio parameter.

Image-to-Image (I2I) Model Characteristics

i2iModels stores metadata for models that transform or enhance an existing image. As implemented in the src/lib/models.js export (defined around lines 2590-2770), these entries include:

• An imageField property (e.g., image_url or images_list) specifying which request field contains the source image(s).
• A hasPrompt boolean indicating whether the model accepts additional text prompts alongside the image.
• Additional controls such as maxImages, num_images, or tool-specific parameters.
• Retrieval via the getI2IModelById utility function.

The Flux Kontext Dev I2I model (flux-kontext-dev-i2i) demonstrates this pattern, requiring an input image list while supporting optional prompts and up to 10 output images.

Source Code Structure

In src/lib/models.js, the exports appear as distinct arrays with their respective helper functions:

// First export in models.js
export const t2iModels = [
  // Text-to-image model definitions
];

export const i2iModels = [
  // Image-to-image model definitions (lines ~2590-2770)
];

export function getT2IModelById(id) { /* ... */ }
export function getI2IModelById(id) { /* ... */ }

The packages/studio/src/models.js file mirrors these definitions for the Studio UI component library, ensuring consistency across the monorepo.

Practical Implementation Examples

Consuming T2I Models

When using a Text-to-Image model like Nano Banana, construct payloads that include only the prompt and optional parameters:

import { t2iModels, getT2IModelById } from '@/lib/models'

const model = getT2IModelById('nano-banana')
const payload = {
  prompt: 'A futuristic city at sunrise',
  aspect_ratio: '16:9'   // optional
}
// Send payload to the model's endpoint (nano-banana)

Consuming I2I Models

Image-to-Image workflows require the source image field specified in the model's imageField property, as shown with Flux Kontext Dev I2I:

import { i2iModels, getI2IModelById } from '@/lib/models'

const model = getI2IModelById('flux-kontext-dev-i2i')
const payload = {
  images_list: ['https://example.com/input.jpg'], // required source image(s)
  prompt: 'Add a magical aurora in the sky',      // optional
  aspect_ratio: '21:9',
  num_images: 3
}
// Send payload to the model's endpoint (flux-kontext-dev-i2i)

Dynamic UI Rendering Based on Model Type

Frontend components use these metadata flags to conditionally render appropriate input fields:

function renderInputs(model) {
  if (model.hasPrompt) {
    // show prompt textbox
  }
  if (model.imageField) {
    // show file uploader tied to model.imageField
  }
}

API Integration and Endpoint Selection

The src/lib/muapi.js module leverages this distinction to route requests correctly. When params.model references an I2I model identifier, the API layer expects the corresponding imageField to be populated in the request payload. This architectural guard prevents malformed requests to image transformation endpoints that would fail without source image data.

Summary

• t2iModels defines Text-to-Image models that generate content from prompts alone, with optional size parameters like aspect_ratio.
• i2iModels defines Image-to-Image models that require a source image via imageField and may optionally accept prompt input when hasPrompt is true.
• Both arrays export from src/lib/models.js with corresponding getter functions getT2IModelById and getI2IModelById.
• The imageField and hasPrompt metadata properties drive dynamic UI generation and API payload validation across the codebase.

Frequently Asked Questions

How do I determine if a model requires an input image?

Check the model's metadata for the imageField property. Models defined in i2iModels include this field specifying which parameter (such as images_list or image_url) holds the source image, while t2iModels entries lack this property entirely.

Can Image-to-Image models accept text prompts?

Yes, according to the schema in src/lib/models.js, I2I models may set hasPrompt: true to indicate they accept both a source image and a text prompt for guided transformation. However, the image field remains required while the prompt is optional depending on the specific model implementation.

Where are these model definitions used in the API layer?

The src/lib/muapi.js file references the model type through params.model to determine whether to call a Text-to-Image or Image-to-Image endpoint. This ensures the API constructs the correct request format based on whether the selected model originates from t2iModels or i2iModels.

Why are the model arrays separated instead of using a single unified list?

The separation enforces type safety and simplifies UI component logic. By distinguishing between t2iModels (text-only generation) and i2iModels (image transformation), the codebase can validate that I2I requests contain the mandatory imageField data and render appropriate file uploaders without conditional complexity in every consumer component.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}