GPT Image 2 — OpenAI's Visual Layer

OpenAI's current image generation line is GPT Image 2 — state-of-the-art per OpenAI's own model card, generally available in the API since April 21, 2026. Its predecessor, gpt-image-1, is now deprecated: OpenAI's deprecation notice (issued April 22, 2026) sets a shutdown date of October 23, 2026, with GPT Image 2 named as the recommended replacement. DALL-E 3 and DALL-E 2 are further back in the past — both were deprecated in November 2025 and fully shut down on May 12, 2026.

This lesson teaches GPT Image 2 as the primary OpenAI model for this track — not because it is simply "the newest," but because of what it verifiably does better: multi-image reference input for identity-consistent edits, reliable text rendering, and stronger handling of complex composed visuals like storyboards, character sheets, and multi-panel layouts. That is the profile that matters for production creative work, and it is why the worked examples in this lesson build on it directly.

Before You Start — Environment Setup

This is the first code-first lesson in the track, and everything from here through the production pipeline lesson assumes a working Python 3.10+ environment. Two minutes of setup:

# Install the packages used across the API lessons
pip install openai httpx

# Set your API key as an environment variable — never hard-code it
export OPENAI_API_KEY="<your-openai-api-key>"

Create the key at platform.openai.com under API keys. Each subsequent provider lesson adds its own key the same way (LEONARDO_API_KEY for Leonardo, GOOGLE_AI_KEY for Gemini) — always as environment variables read with os.getenv(), never as literals in code. If pip, virtual environments, or environment variables are unfamiliar, work through a Python basics primer before continuing — the code in these lessons assumes that fluency.

The gpt-image Line — What's Current, What's Legacy

OpenAI has shipped several image models under two family names. Knowing which are alive matters for anything you ship today:

Model	Status	Shutdown date
dall-e-2, dall-e-3	Shut down	May 12, 2026 (already passed)
gpt-image-1, gpt-image-1-mini	Deprecated	Oct 23, 2026 / Dec 1, 2026
gpt-image-1.5, chatgpt-image-latest	Deprecated	Dec 1, 2026
gpt-image-2	Current — recommended for all new work	—

Building anything new on gpt-image-1 today means shipping a pipeline with a known, dated expiration. There is no reason to do that — GPT Image 2 is generally available now, uses the same /v1/images/generations and /v1/images/edits endpoints, and the migration is a model-string change plus dropping one parameter (input_fidelity — more on that below).

GPT Image 2 — What Actually Changed

Per OpenAI's own GPT Image prompting guide, GPT Image 2 is designed for "production-quality visuals and highly controllable creative workflows," with four capabilities called out specifically:

• Robust facial and identity preservation for edits, character consistency, and multi-step workflows — the exact capability a locked character bible or reference sheet depends on.
• Reliable text rendering, with crisp lettering, consistent layout, and strong contrast inside images — the historically weak point of every diffusion-family model.
• Complex structured visuals, including infographics, diagrams, and multi-panel compositions — storyboards and comic-style layouts included.
• Precise style control and style transfer with minimal prompt engineering overhead.

The mechanics behind those claims:

Multi-image reference input. The /v1/images/edits endpoint now accepts an array of reference images (image=[img1, img2, img3, ...]) instead of just one. Feed it a locked character sheet plus a new background plate and it composites with consistent identity — the pattern behind character-bible and storyboard workflows.

Always-high-fidelity image processing. gpt-image-1 exposed an input_fidelity parameter (low or high) that traded reference-image detail preservation for speed and cost. GPT Image 2 removes the choice — it always processes image inputs at high fidelity. Omit the parameter; the API rejects it if you pass one.

Multi-turn editing. Through the Responses API's image_generation tool, you can iterate on an image across a conversation — generate, then refine with follow-up natural-language instructions, using either previous_response_id or an image ID to maintain context. The Image API (/v1/images/edits) still supports single-shot edits; the Responses API is where iterative refinement lives.

Flexible resolution. Instead of 3-4 fixed presets, gpt-image-2 accepts thousands of valid resolutions — up to a 3840px long edge, both edges a multiple of 16px, long-to-short ratio no more than 3:1. Popular presets remain available (1024x1024, 1536x1024, 1024x1536, 2048x2048, and 4K variants), plus auto for model-chosen sizing.

A real limitation. GPT Image 2 does not currently support transparent backgrounds — background: "transparent" requests are rejected. If your pipeline needs alpha-channel output (logos, sticker sheets, overlay assets), that is a gap to design around, not a feature to assume.

API Integration Pattern — Generation

import openai

client = openai.OpenAI()

response = client.images.generate(
    model="gpt-image-2",
    prompt="A lone astronaut on a red Martian cliff, cinematic photography, golden hour backlighting, wide establishing shot, atmosphere of quiet solitude",
    size="1536x1024",
    quality="high",
    n=1,
)

# gpt-image-2 always returns b64_json — no revised_prompt, no rewriting
import base64
image_data = base64.b64decode(response.data[0].b64_json)

gpt-image-2 Parameters

size: any resolution satisfying the constraints above, or the popular presets (1024x1024, 1536x1024, 1024x1536, 2048x2048, auto). Square renders fastest.

quality: low, medium, high, auto (default). Use low for drafts and thumbnails, medium for most production content, high for final assets and anything with dense text or fine detail.

moderation: auto (default, standard filtering) or low (less restrictive).

n: number of images per request — GPT Image 2 supports n > 1, unlike the old DALL-E 3 which was capped at n=1.

Multi-Image Reference Editing — The Character-Bible Workflow

This is the capability that matters most for locked-identity work: composing a new image from multiple reference images in one request, with the model preserving what should stay consistent (a character's face, a product's shape) while changing what should vary (pose, background, scene).

result = client.images.edit(
    model="gpt-image-2",
    image=[
        open("character-reference-front.png", "rb"),
        open("character-reference-profile.png", "rb"),
        open("wardrobe-reference.png", "rb"),
    ],
    prompt=(
        "Generate this character standing in a rain-slicked alley at night, neon signage "
        "reflected in the wet pavement. Preserve the exact face, proportions, and wardrobe "
        "from the reference images. Do not alter identity, skin tone, or body shape."
    ),
    size="1024x1536",
    quality="high",
)

image_bytes = base64.b64decode(result.data[0].b64_json)

Two prompting habits make this reliable, straight from OpenAI's own guidance: state explicitly what must stay consistent (face, proportions, wardrobe, identity) and what is allowed to change (pose, lighting, background) — and add hard constraints ("do not alter identity," "no extra elements") to prevent drift. Vague edit prompts let the model improvise; explicit constraints don't.

This same pattern — multiple locked references composited into a new scene — is what underlies multi-panel storyboards and reference-sheet-driven character work: generate the reference sheet once, then feed it back in as the identity anchor for every subsequent panel.

Multi-Turn Editing via the Responses API

For iterative refinement within a single working session — "make the lighting warmer," "now widen the shot" — the Responses API's image generation tool keeps context across turns:

response = client.responses.create(
    model="gpt-5.6",
    input="Generate an image of a gray tabby cat hugging an otter with an orange scarf",
    tools=[{"type": "image_generation"}],
)

image_data = [
    output.result
    for output in response.output
    if output.type == "image_generation_call"
]

# Refine in a follow-up turn using the same conversation
response_2 = client.responses.create(
    model="gpt-5.6",
    previous_response_id=response.id,
    input="Now make it look like a watercolor painting",
    tools=[{"type": "image_generation"}],
)

The Responses API adds two things the plain Image API doesn't have: multi-turn editing (iteratively refine with prompting, no need to resend the full context) and flexible inputs (accept image File IDs, not just raw bytes). For a one-shot generation or edit, the Image API shown earlier is simpler. For an iterative creative session, the Responses API is the right tool.

Cost Structure and Volume Planning

GPT Image 2 pricing is token-based: $5.00 per 1M text input tokens, $8.00 per 1M image input tokens, and output priced by quality and size. Representative per-image output costs at common resolutions:

At the volume typical for content pipelines (10–50 images per day) medium quality is the practical default: a blog autopilot generating one hero image per article at ~$0.04 costs roughly $1.20/month at daily cadence. A social pipeline generating 20 images/day at medium quality runs roughly $25/month. Edit requests that include reference images add image-input token cost on top of the output cost — expect edit requests to run somewhat higher than pure generation, since GPT Image 2 always processes reference images at high fidelity.

There is no free tier on GPT Image 2 — every image costs money regardless of volume. That is the reason Gemini's free tier occupies the primary slot in this track's cost-optimized fallback chain, covered next.

Content Policy and Moderation

GPT Image models share a moderation parameter (auto default, low for less restrictive filtering). Blocked requests return a structured error with error.code = "moderation_blocked" and an optional moderation_details object identifying the stage (input or output) and category (harassment, self-harm, sexual, violence). Use error.code as your stable discriminator for programmatic handling — don't parse error message strings, they can change wording without notice.

For production pipelines: do not retry moderation-blocked requests with the same prompt. Redesign the prompt or route to a different provider. Retrying will not help.

Integrating GPT Image 2 into the Fallback Chain

In the cost-optimized production chain covered in the "Building a Production Image Pipeline" lesson, GPT Image 2 occupies fallback #2 — the reliable last resort after Gemini's free tier and Leonardo's cinematic paid tier, for high-volume, low-stakes generations like blog hero images where cost matters more than any single image's fidelity.

That chain position is about cost architecture, not a statement about quality. For work where the images themselves are the deliverable — locked character bibles, multi-panel storyboards, reference-sheet-driven series, anything where identity consistency and text rendering are load-bearing — call GPT Image 2 directly rather than routing it through a cost-first fallback chain built for disposable hero images. Know which category your use case falls into before you pick the integration pattern.

Lesson Drill

Build the generation function and the multi-image edit function from this lesson against gpt-image-2. Generate a base character reference image, then use it (plus at least one additional reference image) in an edit request that places the character in a new scene — verify the face, proportions, and wardrobe stay consistent across the edit. Next, run the same edit prompt through the Responses API's multi-turn pattern: generate, then issue a follow-up refinement using previous_response_id. Finally, check platform.openai.com/docs/deprecations yourself and confirm the current shutdown date for gpt-image-1 — deprecation timelines are live data, not something to memorize from any lesson.

Bottom Line

DALL-E 3 is gone. gpt-image-1 has a shutdown date on the calendar. GPT Image 2 is OpenAI's current production model — generally available, built for the composed visual work (character consistency, multi-panel layouts, text-heavy assets) that this track's worked examples now build on first. It supports multi-image reference input, multi-turn editing, always-high-fidelity input processing, and thousands of valid resolutions — at the cost of no free tier and no transparent-background output. In the production fallback chain, it is the reliable backstop; for character-bible and storyboard work, it is the model you reach for directly.