ChatGPT Images 2.5 arrives in the API with two models and a focus on precise editing

OpenAI announced ChatGPT Images 2.5, the new generation of its image generation models, and the news that matters for builders isn't in the ChatGPT interface, but in the API. As Simon Willison noted on his blog (simonwillison.net), the family gained two new model IDs: gpt-image-2.5-sunburst and gpt-image-2.5-flare. For anyone running a SaaS generating thumbnails, a content automation pipeline, or any feature that depends on on-demand image generation, this fork is the part that changes the code.

The number OpenAI itself uses to justify the scale is impressive: according to the material cited by Willison, the company's image models have already been used to generate "over 3 billion images across ChatGPT Images and the GPT-Image models via API". In other words, this isn't a demo toy, it's infrastructure already running at production volume.

Sunburst vs. Flare: choosing the model became an architecture decision

Until now, integrating image generation with OpenAI meant picking a model and sending the prompt. With 2.5, the decision now involves an explicit trade-off axis between editing precision and speed/cost per everyday image. The documentation itself sums it up like this:

Choose Sunburst for workflows where editing precision matters most, and Flare for fast, high-quality everyday image generation.

>

-- OpenAI, via Simon Willison

Willison's reading is straightforward: Sunburst is the stronger model, recommended for workflows where editing precision matters most (retouching, adjusting, respecting composition). Flare is the workhorse for high-volume generation, where you want good quality and fast responses without paying the price of the more expensive model.

In practice, this means a decision that used to be binary (use the image API or not) now has an intermediate engineering step:

| Scenario | Suggested model | Why | |---|---|---| | Editing a product photo while preserving the object | gpt-image-2.5-sunburst | Editing precision and fidelity to the reference | | Generating 500 banner variations per day | gpt-image-2.5-flare | Speed and cost per image at volume | | Retouching with multiple instruction turns | gpt-image-2.5-sunburst | Better adherence to chained instructions |

A word of caution: the source doesn't provide a pricing table or measured latency numbers for the two models. So "cheaper" and "faster" here are OpenAI's positioning promise, not a benchmark. Before switching your pipeline's model, measure the cost per image at your actual volume, both IDs need to go through an A/B test with your own prompt and your own reference.

The three improvements OpenAI highlights

According to the cited release, 2.5 improves on three concrete fronts:

1. Multi-turn instruction adherence: the ability to keep context when you refine the image across several messages ("now make the background darker", "increase the text contrast"). This is what hurts automation the most: a model that "forgets" the previous instruction forces you to rewrite the entire prompt at every iteration.
2. Faster response times: directly relevant to infrastructure cost and to the experience of any synchronous feature, where the user waits for the image to load.
3. Preservation of subjects in reference photos: in the material's own words, the model "is better at preserving the subjects in your reference photos". This is the point that unlocks serious use cases: editing a product photo without distorting it, keeping a character's face consistent across generations, placing a new element into an existing scene without breaking the rest.

The concrete case: reference images via CLI

Willison did what he usually does: he updated his command-line tool openai_image.py to accept one or more reference images and tested it right away. The command he published gives the most tangible example of what this looks like in the terminal, using uv to run the script directly from the URL:

uv run https://tools.simonwillison.net/python/openai_image.py \
  'add a raccoon scientist studying the chart thoughtfully' \
  -i https://static.simonwillison.net/static/2026/openai-agent-usage.webp \
  -m gpt-image-2.5-sunburst

Here's what's happening: the -i flag passes the reference image (a chart), the prompt asks to add a raccoon scientist studying the chart, and -m selects Sunburst. The model receives the original image and the editing instruction, and returns the modified version while preserving the chart. This is exactly the "edit while preserving the subject" flow OpenAI is selling, tested with a one-line command.

For the Brazilian developer, the detail of uv run pointing directly to a URL is a pattern worth copying: it lets you distribute an image-generation tool without requiring pip install, venv, or a repository clone. The user only needs uv and the environment variable with the OpenAI key.

What this changes in your pipeline

If you already run image generation in production, the arrival of 2.5 raises two questions again:

• Cost versus quality now has two points on the curve. If today you use a single model for everything, you're probably overpaying for trivial generation or delivering low quality on fine editing. Segmenting calls between Flare (volume) and Sunburst (critical editing) is the obvious optimization, and one you can measure in your billing.
• Reliable references open up cases that used to be fragile. Character consistency, product retouching, and compositing onto an existing image were exactly where diffusion models used to slip up. If the preservation improvement holds up in your own testing, you can promote these flows from "experiment" to "feature".

Where it's not worth migrating blindly: any pipeline that depends on predictable cost shouldn't switch models without first running its own volume through both IDs and comparing the bill. And if your case is local or offline generation (not relying on a paid API), 2.5 changes nothing, it's a closed OpenAI service, not an open model you download and run on your own hardware. For those scenarios, the stack remains open models running locally.

The release is short, but the technical message is clear: OpenAI turned "generating an image" into a decision with two SKUs, and builders need to treat model choice as part of the architecture, not as a default. The best test remains the one Willison did: take your own prompt, your own reference image, run both models, and measure.