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

> Explore t2iModels vs i2iModels in models.js. Learn how Text-to-Image models create visuals from text prompts while Image-to-Image models transform existing images.

- Repository: [Anil Chandra Naidu Matcha/Open-Generative-AI](https://github.com/Anil-matcha/Open-Generative-AI)
- Tags: deep-dive
- Published: 2026-04-24

---

**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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/src/lib/models.js), the exports appear as distinct arrays with their respective helper functions:

```javascript
// 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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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:

```javascript
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:

```javascript
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:

```javascript
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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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`](https://github.com/Anil-matcha/Open-Generative-AI/blob/main/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.