GPT Image 2.5 vs GPT Image 2: what actually changed

Start with the part that saves you the most work. The API surface is the same. You still post to the image generations endpoint and the image editing endpoint. You still send text and images. You still get images back and nothing else. No new authentication, no new SDK, no new response shape to parse.

Pricing did not change either. Text input, image input, and image output bill at the rates GPT Image 2 already charged, with the same discounted rates for cached input. A generation upgrade that costs nothing extra is unusual, and it removes the one argument that normally delays this kind of migration. You do not need a new budget line to move.

The mental model for cost is also unchanged. You are billed on tokens, not on images. A higher quality tier and a larger output produce more image tokens and therefore cost more. OpenAI publishes token rates and no official per image price table. Any per image figure you find comes from a third party host, and it belongs in a spreadsheet labeled with that vendor name.

What did change structurally is that one model became two. GPT Image 2 gave you a single choice. Images 2.5 splits that choice into a fast default and a precision option. If your code assumed exactly one image model id, that assumption is now a routing decision you get to make. Most teams should make it explicit rather than hardcoding whichever id they migrated to first.

Your prompt library did not become obsolete either. Formats that worked on GPT Image 2 still work. You may find that instructions you once added to compensate for the older model are now unnecessary, especially hedges about lighting and material detail. Strip those gradually and compare results, rather than rewriting every prompt on day one.

The review burden did not change at all. Both generations produce images that need human approval before publication. Text inside images, brand marks, hands, and product geometry still deserve a careful look. A faster model shortens the wait before review starts. It does not replace the reviewer, and no published figure suggests otherwise.

Rate limits still scale by usage tier, and images per minute remains the constraint that bites first for batch workloads. If you generate in bulk, check the tier you actually sit in before you assume the faster model will double your throughput. Latency and rate limits are separate ceilings, and a faster model does not raise the second one.

For API users the answer is yes, and the work is small. Change the model string to gpt-image-2.5-flare and run your existing prompts. The request body, the endpoints, and the billing model all stay put. If your prompts already work, they will keep working. Budget an afternoon for the swap and a day for reviewing outputs.

Pin the snapshot once you are satisfied. The ids are gpt-image-2.5-flare-2026-09-08 and gpt-image-2.5-sunburst-2026-09-08. Pinning protects you from silent style drift when a default moves. Keep the unpinned alias running in staging so you meet new behavior before your customers do. This discipline costs nothing and it saves an incident.

Review the outputs properly, because this is the part teams skip. New generation, new visual character. Images 2.5 will not reproduce your GPT Image 2 catalog pixel for pixel. If you have a published library generated on the older model, regenerate a representative sample and look at them side by side before you flip everything. Lighting and texture changed for the better, but they changed.

Test your edit heavy paths on both models. Anywhere a user submits an image and requests a specific change is where the precision model may earn its extra time. Anywhere the model runs behind a loading spinner is where the fast model is almost always correct. Draw that line once and encode it as a routing rule instead of a per project debate.

On latency, do not take any published multiplier as a promise for your prompts. Speed depends on your quality tier, your output size, and how much your prompt asks for. We are running our own timings across a fixed prompt set on both models, and this page will carry a measured table once those runs finish. Until then, measure on your own traffic before you rewrite a queue around expected speed.

One group should move slowly. If you generate assets that must match an existing published set, treat this as a visual change and not a version bump. Run both models over the same prompts, place the results beside your live work, and judge whether the difference reads as an improvement or as an inconsistency. Then migrate the whole set at once.

For everyone else this is closer to routine maintenance. The cost is identical, the interface is identical, and the newer generation scores better on the published safety measurement. Delaying buys you nothing except a longer list of call sites to update later, and older models do not get faster while you wait.

ChatGPT users have nothing to migrate. The release went out to ChatGPT, ChatGPT Work, and Codex users at every tier, across desktop, mobile, and web. The new tools appear in the product. The only action worth taking is learning Sketch and version history, because both change how you work rather than just how the output looks.