Build Hour: Image Gen

🖼️ Introduction — The moment ImageGen went mainstream

I presented a Build Hour on ImageGen for OpenAI, and today I want to report on what we announced, demonstrated, and explained to builders. The short story: ImageGen sprinted from ChatGPT to the API, and developers are already using it to build new user experiences—everything from an AI-powered photobooth to presentation platforms that auto-generate visuals.

To set the stage with a couple of headline numbers: in the first week after ImageGen launched in ChatGPT, people created images in the hundreds of millions—over 700 million images—and more than 130 million users tried ImageGen. That immediate, massive adoption showed us two things: (1) people want to create images with natural prompts, and (2) developers will want the same capabilities inside their own apps. That’s why I moved quickly from chat to API access and then focused this Build Hour on the API features that matter most for production apps.

In this article I’ll recap what ImageGen is, how it differs from previous text-to-image models, the new capabilities that ship in the API (including Responses API improvements), the live photobooth demo I built, a customer spotlight from Gamma, and the best practices and limitations you should plan for. I’ll also walk through concrete implementation patterns and answer the most common questions I received during the Q&A portion of the session.

⚙️ What ImageGen is — architecture and core differences

When I first explained ImageGen during the Build Hour, I wanted to be clear about one thing: ImageGen isn’t just “another diffusion model.” Historically, many popular image-generation systems were diffusion-based or optimized around denoising processes. ImageGen is different: it is native to the GPT-4o family. It is a GPT-native image generation model—what I described in the session as a GPT-4o image-first architecture.

That matters because ImageGen produces images auto-regressively—similar to how GPT generates text tokens. In other words, the model predicts the next token in a sequence, and for images those tokens correspond to visual elements rather than characters. Conceptually this is a token-by-token (or block-by-block) image generation process that behaves like text generation, and it unlocks capabilities that were harder to achieve with diffusion-only systems.

There are three immediate practical differences you should expect because of this architecture:

Text rendering on images: Because the model learns to generate images in a tokenized, sequential manner, it has stronger capability to render legible text on images and to place text on different surfaces (handwritten, neon, printed on shirts, etc.).
Improved instruction following: The GPT backbone carries all the advantages of large language model (LLM) reasoning. That translates to better one-shot and zero-shot responses to requests like “create a science poster for photosynthesis with labeled cellular components.”
Granular, multi-turn editing: ImageGen supports multi-step dialogues that edit images incrementally. You can provide an existing image and a follow-up instruction (e.g., “make the background darker and add the OpenAI logo to the shirt”), and the Responses API can generate the edited image while maintaining composition consistency.

In the session I contrasted ImageGen’s approach with diffusion-based experiences and emphasized how the GPT-native model blurs the line between “design is an iterative dialogue” and “design as a static generation.” Rather than one-shot image dumps, ImageGen encourages iterative refinement, tool orchestration, and multimodal reasoning.

🚀 New API capabilities — Responses API and gpt-image-1

By the time I gave the Build Hour, ImageGen was available in two API flavors: the standalone Image API and as a built-in tool inside the Responses API (the latter uses the gpt-image-1 tool invocation with a Responses API session). I explained that for many production scenarios the Responses API is the right entry point because it enables multi-tool orchestration and multi-turn experiences.

Last week we shipped several improvements that I demonstrated live. They are:

Streaming: You can now stream partial image renderings back to the client while the model continues to generate. This greatly improves perceived latency and allows for progressive UI updates (think a canvas painting in gradually).
Multi-turn editing: Every image response includes an ID. Instead of re-uploading the entire base64 image again, you can pass the response ID back into the Responses API and request edits or derivatives. This makes iterative workflows much more efficient.
Multi-tool image generation: Because ImageGen can operate inside Responses API, you can combine tools—like web search—into a single coherent flow. The model can decide to call the web search tool first, gather current facts, then call the image tool to render an updated image with real-time data.
Masking and inpainting: You can supply a mask to selectively modify parts of an image. The mask approach still exists and is useful when you want tight control over which pixels change.
Maskless editing (also known as context-aware editing): The GPT-image models can often accept natural language modifications without a mask and infer which parts of the image to alter—useful for quick editing iterations inside UI flows.

Those capabilities are transformative for builders because they bring image generation into the same orchestration framework you’d use with text agents, web tools, and other plugins. You no longer need to implement lots of glue code or external orchestration to combine web lookups with image renders—the Responses API handles that interplay naturally.

📸 Live demo — building an AI photobooth (what I showed)

One of the most concrete parts of the Build Hour was a live demo: an AI photobooth built with Next.js that allowed users to upload a single photo, then apply stylistic modifiers and edits via ImageGen. I built the prototype for an internal Exec Summit and then repurposed it for the live presentation to highlight the Responses API improvements.

Here’s how the photobooth worked and what I emphasized during the demo:

Upload a base photo: I uploaded a prepared portrait of myself and used that as the input image to generate multiple stylized variants.
Select modifiers: The UI had buttons such as “Studio Ghibli style,” “knitted cozy scene,” “Japanese anime movie poster,” and “minifigure.” Each button mapped to a short natural language modifier prompt that the app then assembled into a system prompt for the image tool.
Streaming partials: While the model generated, the frontend showed streaming partial images for each variant. In the browser’s developer console I could see partial image events and final image events; partials were applied to the front end as they arrived, and a final image replaced the partial when generation completed.
Multi-turn edits: With the image generated, attendees then voted on edits via chat. I passed the response ID back to the Responses API and asked it to change the background’s shade of green, and later to add an OpenAI logo to the shirt. The model returned edited images that preserved the subject composition while implementing the requested edits.
Tool orchestration live: For one final trick, I demonstrated a multi-tool flow where I asked ImageGen to include the most recent Knicks vs. Celtics score as a background element. Because the Responses API had a web search tool in its tool list, the model autonomously called web search, fetched the current score, and then called the image tool to compose the image with the score rendered.

A few practical notes from the demo:

Image generation typically took 30–60 seconds depending on size and quality settings. Streaming made the wait feel shorter.
I configured the Responses API tool invocation as “required” so the model would always call the image tool. That’s a helpful pattern when you have a single guaranteed action you want the model to perform.
You can supply either a base64 image input or a previous response ID; the latter is often preferable to avoid re-uploading large binary payloads during multi-turn edits.

🧭 Best practices and UX tradeoffs

After running through capabilities and the demo, I shared practical guidance for developers planning production use. These are the patterns and tradeoffs I recommended.

Choose the right API: responses vs. image

ImageGen is accessible in two forms:

Image API: Use this for single-turn tasks where you just need to generate one image from a prompt with minimal orchestration.
Responses API (with gpt-image-1 tool): Use this for multi-turn flows, editing workflows, streaming, nudging, or when you want the model to orchestrate multiple tools (web search, custom tool calls, etc.). For most production-grade apps, Responses API is the better choice because of its flexibility.

Prompt engineering and consistency

Prompting matters. It’s both art and engineering. I recommended builders be explicit in prompts, avoid conflicting instructions, and provide examples or reference images whenever possible. When you need consistent characters, props, or style across multiple generated images, pass reference images for the model to match against instead of relying solely on textual style descriptions. The Responses API’s multi-turn pattern makes it easy to re-use prior outputs as references.

Size, quality, and tokens

Image quality setting affects latency and cost. I advised teams to start at the highest quality to see the model’s ceiling, then experiment with lower quality presets if cost or latency requires it. Keep in mind that images are tokenized and larger outputs consume more resources, so fiscal planning is essential when using image generation at scale.

Latency and perceived speed: use streaming

ImageGen generation can take time. The best UX pattern is to stream partial image frames (or progressively refined JPEG/WebP assets) to the user so they see something immediately and enjoy an incremental reveal rather than a long, empty spinner. Streaming not only improves perceived responsiveness, it reduces abandonment.

Mask vs. maskless editing

Use masks when you need surgical control of which pixels should change. Masks are alpha-channel images that indicate editable regions. Use maskless editing where the model should infer the edits from a natural language instruction (faster iteration, higher-level control). For consistent results in complex compositions, prefer masks plus a clear edit instruction.

Tool orchestration and real-time data

When your image needs live facts (scores, weather, product inventory), include a relevant search or tool in the Responses API’s tools array. The model will decide whether to call that tool. If you need deterministic tool execution, mark the tool as required. This same pattern applies to price lookups, social metrics, or live dashboards rendered as image overlays.

💡 Use cases and builder ideas

During the session I threw out a variety of ways teams could use ImageGen. I want to expand on those because the list was intentionally short in the presentation and the community asked for more inspiration.

E-commerce and virtual try-on

Imagine letting customers upload a photo and preview how a dress or pair of glasses would look on them. Using image inputs (customer photo + product image) you can composite photorealistic try-on images in a consistent style and angle. For inventory-heavy sites you can automate product photography with style templates.

Marketing and on-the-fly creatives

Marketers can create presentation slides, poster graphics, and social assets programmatically via templates. The model can render layouts with text, icons, and brand colors. Because ImageGen supports text rendering, you can generate hero banners with headline copy directly rendered on the image.

Games and asset generation

Indie game developers reported struggle for years sourcing sprites and assets. With ImageGen you can generate character sprites, environment tiles, and promotional art tailored to the game’s aesthetic—RPG makers can now iterate art direction rapidly without contracting dozens of freelancers.

Education and scientific visual aids

ImageGen’s world knowledge (drawn from the GPT backbone) helps create diagrams, labeled biology posters, and conceptual visuals from one-line prompts. Teachers and edtech platforms can create on-demand images to accompany lesson plans or interactive modules.

Presentations and document visuals

Platform developers (like Gamma) can auto-generate image slides, hero images, and diagrams as part of a full presentation flow. Images become a first-class component of a document rather than an afterthought.

🧩 Gamma spotlight — how a customer integrated ImageGen

I invited Jordan, Head of AI Engineering at Gamma, to present how Gamma uses AI images. Gamma is a platform that helps users build presentations, and imagery is core to their experience. Jordan explained that Gamma generates around 700,000 AI-powered presentations per day and has crossed a billion AI images across the platform using multiple providers, including ImageGen.

Jordan highlighted three pillars in Gamma’s visual approach:

Charts and diagrams
Visualizations and layouts
AI-generated images

Some practical points Jordan shared that builders should note:

WebSearch as a tool: Gamma uses web search to avoid hallucinated details when the presentation relies on facts beyond the model’s training cutoff. The Responses API’s built-in tool pattern makes it straightforward to fetch up-to-date references and then generate images with real facts.
Maskless editing wins: Gamma moved to gpt-image-1 for maskless editing and saw a measurable 27% increase in user-rated improvement for edited images. That’s a huge gain from a single integration change: one-line code changes can yield significant UX improvements.
Human-in-the-loop control: Gamma allows users to provide images (like speaker headshots) to prevent the platform from generating facsimiles of real people—an important product safety and ethical design choice.

Overall, Gamma’s example illustrates a typical productized workflow: synthesis (gather content), layout (choose visuals and slide arrangements), and image generation (render images and refine). They use ImageGen for both creation and editing inside the same pipeline, which is a great pattern for other presentation or document platforms to follow.

🎯 Multi-turn editing, masking, and image inputs — how to orchestrate

I spent a lot of time in the Build Hour walking through the multi-turn editing lifecycle because it’s the feature that most product engineers find both powerful and a little confusing the first time around. Here’s the pattern in practical terms.

Step-by-step multi-turn edit pattern

User uploads an initial image (or you supply a reference image from your catalog).
You create a Responses API session and call the image tool with the initial prompt and the uploaded image (or include it as a base64 payload).
The Responses API returns a response that contains partial events (if streaming) and a final image. The final response includes a response ID and an image asset ID.
For each follow-up edit, you pass the response ID (or the image asset ID) back into the Responses API as part of the new request and include the new instruction (e.g., “make background darker; add logo to shirt”).
The model uses the response ID to reference the prior context, apply the instruction, and return a new edited image. You can repeat this loop as many times as needed.

Why use a response ID instead of re-uploading the image?

Efficiency: avoids uploading large binary blobs repeatedly.
Stateful references: the model can reason over the historical chain of edits, making it easier to keep composition and style consistent.
Simpler client code: you don't need to manage multiple copies of images in the client or backend.

Mask strategy

If you need pixel-accurate edits, create a mask image where the editable region is transparent (alpha) and the protected region is filled. When the image tool receives the image+mask pair, it will only modify pixels within the masked area. Masks are ideal for replacing backgrounds, swapping faces, or touching up product photos without disturbing the untouched areas.

Maskless editing

Maskless editing lets the model infer the area to change from a natural language instruction. It’s faster from a UX standpoint because you don’t need a mask editor in your front end; however, maskless edits are probabilistic and sometimes require refinement or retries for precise results. Gamma’s experience shows strong practical value for maskless flows, especially when combined with a user approval or rating loop to continuously calibrate prompts.

🔍 Prompting, consistency, and debugging images

Several builders asked about how to achieve consistency across a set of images (e.g., same character, consistent style). My core advice was twofold: prompt well and provide references. Here are actionable rules I use:

Be explicit: Include clear camera parameters, lighting, style name, and reference artist if that’s part of the desired look. For example: “Studio Ghibli style, med-close shot, warm ambient lighting, subject centered, subtle film grain.”
Use reference images: If you want to reuse the same subject or prop, pass that image as an image input. The model is better at matching visual fidelity than trying to reproduce a named character from text alone.
Validate prompts with a language model: I recommended taking your image prompt and running it through a GPT model (like GPT-4o or text-based playground) to proof the text. Models are great at catching contradictions and clarifying ambiguous language in prompts.
Iterate with multi-turn edits: Rather than trying to capture everything in one prompt, consider a staged process (generate a base image, then request color/style adjustments, then fine-tune details with maskless edits).

When you see mutation problems (unexpected artifacts, incorrect details, or inconsistent limbs/hands), follow a debugging loop:

Check for conflicting instructions in the prompt.
Add helpful constraints (e.g., “do not change the subject’s pose” or “keep hands visible and anatomically correct”).
Use a mask to protect areas that must remain unchanged.
Try a higher quality render to determine whether artifacts are a result of lower-quality settings.
If the problem persists, convert the problematic element into a more constrained reference image to ensure fidelity.

🧰 Implementation notes and code walkthrough (how I wired the demo)

I walked through the demo’s implementation during the Build Hour, and the code is available in the public Build Hours repo. Here are the architecture and implementation choices I made for the Next.js photobooth so you can replicate or extend it.

Front-end

Next.js for the frontend with a simple upload flow.
Client maps UI modifier buttons to short modifier snippets and sends the assembled prompt to an API route.
When the Responses API is invoked, stream events (partial images) to the client via SSE/websocket or standard streaming fetch, updating the DOM as partials come in. Replace partial images with final images when the final event arrives.

Server/API route

Create a Responses API call with the input that includes the uploaded image (base64 or response ID) and the assembled prompt.
In the tool list for the Responses API session, include the image tool (gpt-image-1) and any other needed tools (web search, custom tool for inventory or pricing). If you require the image tool to be used every time, set its choice to “required.”
Set stream=true if you want partial events returned.
When receiving partial events in the server stream handler, forward partial image bytes and IDs to the client to render progressively.

Multi-turn edits

When the client requests a modification, pass the previous response ID (or image asset ID) back to the Responses API in the new session input.
Include the new instruction string and the tool list. The model will use the response ID to reference the prior image and return an edited image.

Practical tips

Use server-side session state to manage response IDs and image IDs so clients can send a small identifier rather than large binary payloads.
If storing images, be mindful of retention policies, privacy, and whether you need to obfuscate or anonymize user photos.
Monitor cost and throughput: batch tests to quantify per-image cost at different quality settings; use that to plan budgets for production usage.

⏳ UX, latency, and streaming considerations

Latency is the single-handed user experience factor that matters most for image generation. You can take several steps to manage it effectively:

Start with a preview: show a low-resolution placeholder or a cached generic image while the model prepares its first partials.
Stream partials: progressively deliver partial image results and update the canvas in place so the user sees progress. That’s what I demoed in the photobooth.
Use optimistic UI when safe: if a simple text-only confirmation is needed (e.g., “We’re generating your image”), show that immediately and then swap in the image when it arrives.
Provide progress and fallback: show expected wait time and a cancel/retry button. If the generation fails moderation or hits an objection, present a clear reason and alternative options.

Streaming also has design implications: partial frames might look unfinished—make it feel intentional by designing a progressive reveal, like brush strokes or a glimmer overlay that masks low-fidelity partials until finalization.

🛡️ Moderation, safety, and content policy

I emphasized during the Build Hour that all ImageGen outputs adhere to OpenAI’s content policy. This means image generations that would create disallowed content (violent, sexually explicit, illicit instructions, etc.) will be blocked or rejected by the moderation filter.

Technical points about moderation:

The API exposes a moderation parameter you can tune for sensitivity. If your product is highly permissive for benign art, you should still be conservative around safety-critical categories.
Not all legitimate artistic intent circumvents moderation—for example, depictions of graphic violence or sexual content will be disallowed even in an artistic context.
Plan user flows for failures. If an image generation request is refused, present a constructive explanation and alternatives rather than a generic error.

Ethical considerations:

Be cautious when generating images of identifiable public figures or real people. Product UX should provide opt-in/opt-out controls and use user-supplied images responsibly.
Respect copyright and trademark constraints. Avoid asking the model to reproduce copyrighted artworks verbatim or to create logos that are confusingly similar to protected marks without clear permission.

❓ Q&A highlights — practical questions builders asked

At the end of the session we fielded many great questions. Here are the most common ones and the answers I provided.

Consistency and granular control (object references, style)

Answer: Use specific prompts and pass in image references. Prompt specificity and reference images are the two biggest levers. If you need an object to appear consistently across multiple renders, supply a reference image and call the model in a multi-turn chain, reusing the prior output as the reference.

Handling “mutation” problems (unexpected changes)

Answer: Look for contradictory prompt text first. Use a language model to proof your prompt. If ambiguity exists, tighten the instructions or use a mask to protect areas that must remain unchanged. Multi-turn editing helps you converge to the desired result rather than attempting to capture everything in one prompt.

Best practice for storybooks with interspersed text and images

Answer: ImageGen can work well for stories, children’s books, and educational sequences. I suggested starting with high quality so you understand the model’s ceiling, and then iterate on cost and size. Use multi-turn editing to maintain style and character consistency, and pass images as references for recurring characters.

How to isolate the editable region (masking)

Answer: Use an alpha mask image where the transparent region designates editable pixels. The model will preserve the non-transparent (protected) region. Mask conventions are documented in the Image Gen documentation and are a robust way to ensure fidelity where you need it.

📚 Getting started — resources and links

If you want to try what I demoed, start here:

Code repo: https://github.com/openai/build-hours — the photobooth demo is included in the Build Hours repository where I’ll push updates from the session.
Image Gen Guide: https://platform.openai.com/docs/guides/image-generation — technical reference for parameters, masking, and examples.
Sign up for upcoming Build Hours: https://webinar.openai.com/buildhours — we host regular sessions on other topics like Voice Agents.

In addition to these links, I recommended browsing the ImageGen gallery on the OpenAI site to see sample prompts and inputs that produced specific results. Studying those prompt-to-image pairs is a fast way to learn what wording leads to desired results.

🏁 Conclusion — what I want you to take away

ImageGen marks a meaningful evolution in image generation because it’s built on the GPT family rather than being a purely diffusion-based tool. That architecture unlocks better instruction following, text rendering, multi-turn editing, and multi-tool orchestration inside a single Responses API session.

My practical advice to teams considering ImageGen:

Start with Responses API for production experiences that will need multi-step edits or tool orchestration.
Experiment with streaming to improve perceived latency and make your UI feel more interactive.
Use reference images for consistency across multi-image projects (stories, product catalogs, game assets).
Design fallback flows for moderation and failures so users understand what happened and can try alternative options.
Measure cost at multiple quality tiers—start high to validate the visual ceiling, then tune down as needed.

Finally, I want to echo what I said during the session: the best way to learn ImageGen is to build. The photobooth demo I showed is intentionally simple—the power comes from composing multi-turn edits, streaming, and tool calls. The Build Hours repo includes the code we used, and I’ll be updating it to reflect the improvements we discussed. Go fork it, hack on it, and share what you build—I’m excited to see the creative product experiences you’ll ship with ImageGen.

"Design can be thought of as a dialogue." — Bill Chen

See you in the next Build Hour. If you want to follow up directly, the repo and docs contain everything you need to prototype and iterate quickly.