OpenAI’s own framing for its September 8, 2026 release was that ChatGPT Images 2.5 is the company’s new state-of-the-art image model, with sharper details and more precise editing. That’s the pitch. My first reaction, as someone who spends most of the week feeding prompts into image tools and then quietly deleting the results, was less about the “state-of-the-art” part and more about a smaller detail buried in the coverage: this update goes after the three complaints people had about Images 2.0. Slow generation. Subjects morphing between edits. That second one is the interesting admission.
Because a model that produces a beautiful image is table stakes now. A model that produces the same person twice in a row is what actually determines whether you can use it for real work.
What actually shipped
Three things worth tracking here, and they’re aimed at different users.
- Speed. Reported latency cuts of up to 50% compared with Images 2.0. “Up to” is doing work in that sentence, as it always does, but even half of that improvement changes how you work.
- Sketch. A new feature invoked by typing
@Sketch, which lets you draw directly inside ChatGPT and use that drawing as a reference for generation. - Two API models. GPT-Image-2.5 Flare and GPT-Image-2.5 Sunburst. Flare carries the same quality, editing, and speed gains and is the default for most apps. Sunburst adds more precision for detailed editing.
There are also templates for popular formats, which sounds minor and probably isn’t, if you’ve ever tried to talk a model into a clean 16:9 social card without it inventing text.
Sketch is the part I care about
Prompting for images has always had a translation problem. You know exactly where you want the subject standing, how the frame is cropped, which direction the light comes from. Then you type 240 words trying to describe it, and the model gives you something adjacent but wrong, and you type 260 words, and now it’s wrong differently.
A drawing skips the translation. Even a bad drawing carries spatial information that paragraphs can’t. Composition, scale, placement, rough gesture. If Sketch genuinely respects the layout you give it, that’s a real reduction in iteration count, which is where image tools actually cost you money and patience.
The open question, and I want to be clear that I have not tested this yet, is how strictly the model treats your sketch. Reference implementations tend to fall into two camps. Some treat your drawing as a suggestion and drift toward whatever the prompt implies. Others hold the layout so tightly that your wobbly stick figure proportions survive into the final render. Neither extreme is what you want. The useful middle is a tool that keeps your geometry and improves your execution, and that balance is not something a launch post can tell you about. You find it out on the fifth attempt at a specific job.
Flare versus Sunburst, and why the split matters
The two-model API split is the most practical decision in this release for anyone building on top of it. Flare as the default for most apps, Sunburst for detailed editing precision.
That’s a cost and latency decision dressed up as a quality decision, and I mean that as a compliment. Most product surfaces do not need maximum precision. They need fast, consistent, cheap enough to run on every user action. Reserving the heavier model for the cases that genuinely need pixel-level control is how you keep an image feature from becoming a line item that someone kills in six months.
If you’re integrating, the honest advice is to route by task, not by ambition. Thumbnail generation, avatars, quick variations, background swaps: Flare. Client-facing edit workflows where a customer will zoom in and complain about a hand: Sunburst.
What I’d test before believing any of it
My standing checklist for any new image model, and the one I’ll be running on this:
- Identity across edits. Generate a person, then make five sequential edits. Do they stay the same person? This is the complaint OpenAI says it addressed, so it’s the first thing to verify.
- Sketch fidelity. Draw a deliberately awkward composition. See whether the model keeps it or politely overrules you.
- Real-world speed. Not benchmark speed. Speed at 4pm on a Tuesday under load.
- Text rendering. Still the fastest way to find a model’s limits.
The pattern I’ve noticed across image tool releases is that speed improvements are usually real and quality claims are usually partially real, but consistency improvements are the ones that either transform your workflow or don’t move it at all. There’s no middle ground. Either the face stays the same or you go back to the old process.
Targeting consistency instead of raw fidelity is the right instinct. Whether the model delivers is a question for the fifth edit, not the first, and I’ll report back once I’ve made it that far.
🕒 Published: