GPT Image 2.5 Flare vs Sunburst: which model to call

OpenAI released both models on the same day, from the same generation. They share endpoints, quality settings, token prices, and supported inputs. That makes the choice narrower than a normal model comparison. You are not trading money against quality. You are trading wall clock time against editing precision.

Flare is the default model. OpenAI positions it for everyday generation and cuts latency against Images 2.0. External evaluations found it returning images several times faster than GPT Image 2. That speed changes what you can build on top of it. A Flare call fits inside a request a user is actively waiting on. It also survives large batches without clogging your queue.

Sunburst is the slower model. OpenAI positions it for editing precision. It is the one to reach for when the instruction is specific and the result has to land on the first attempt. Nothing about it is cheaper or more expensive per token. You pay in latency and you get back fidelity to the edit you asked for.

Both models inherit the same generation level improvements over Images 2.0. Lighting reads more naturally. Textures carry more detail. Subjects from a reference photo survive an edit better than they used to. Instruction following holds up across several editing turns instead of drifting after the second one. None of that is exclusive to either model.

Safety scores separate them slightly. Sunburst records the lowest unsafe generation rate of the three models measured. Flare sits between Sunburst and the Images 2.0 baseline. Both improve on that baseline. If your product serves user submitted prompts, this row of the table below deserves a look before you finalize a moderation budget.

The practical consequence is that most teams end up calling both. Flare handles drafts, thumbnails, variations, and anything a person watches load. Sunburst handles the final pass that a client will inspect closely. Routing on that boundary costs you one conditional in application code and no change to your billing model.

One thing neither model changes is your review process. Both still produce images that need a human eye before publication. Text inside images, hands, product logos, and legal marks all remain worth checking. Faster generation moves that check earlier, it does not remove it.

Those figures put Sunburst slightly ahead, which is the opposite of what OpenAI describes and the opposite of what we saw in an earlier pair of one-off calls, where Flare returned in 15 seconds against Sunburst at 29. The spread across three identical Flare runs was six seconds, wider than the gap between the two models.

The explanation is the route rather than the models. An aggregator holds requests in its own queue, and that queue moves with whatever else is running on it. It sits between you and the model, and at these timescales it is the larger term. Our numbers measure the queue.

So we are not going to publish a latency verdict from them. OpenAI states Flare is up to 50 percent faster than the previous generation, and that claim is about the model called directly. If latency decides your architecture, measure it on your own key, at your own concurrency, at the size and quality you actually ship. Anyone quoting a clean two-way split from a hosted endpoint is quoting their queue.

The one thing the runs do establish is that both models work, both hold quoted text, and neither is slow enough to rule out an interactive interface. Every image in our prompt library came out of these same endpoints.

Both models take reference images. Through the OpenAI API you post the file itself to the edits endpoint and the model works from it. Through an aggregator you pass a URL, and that is where the trap is.

Aggregators do not agree on what to call the field, and one of them disagrees with itself. On the host we use, the GPT Image models read `input_urls` while most of its other models read `image_urls`. Sending the wrong name does not fail. The request is accepted, the credits are charged, and the job runs as if no reference had been supplied, returning something with no relation to the image you sent.

We got this wrong ourselves first. Seven plausible spellings all behaved that way, and a run that should have changed one field on a supplied boarding pass invented a different airline instead. With the right name, the same request preserved the airline, the route, the flight number, the gate, the stub and the barcode, and changed only the seat.

The lesson generalises past one vendor. Verify rather than trust the parameter list: send a reference carrying one unmistakable detail, ask for one small change, and check the detail survived. If it did not, that provider is generating from your prompt and ignoring your image, whatever its documentation says, and nothing in the response will tell you.

Three jobs justify the wait. Product photography, packaging typography, and multi turn local edits. All three share one trait. A small region of the image decides whether the whole output is usable.

Product photography is the clearest case. The buyer cares about the product, not the backdrop. A drink can has to keep its shape. A shoe has to keep its stitching. A watch face has to keep its markers. Sunburst is the model built for that kind of preservation, and a reshoot costs far more than the extra seconds per request.

Packaging typography is the second case. Text inside a generated image is where these models historically fall apart. If your brief includes a label, a carton, a menu, or a shop sign, the letters carry the meaning of the whole picture. Generate those on Sunburst. Then check them by eye anyway, because no image model guarantees correct text.

Multi turn local edits are the third case. You send an image, ask for one change, then ask for another change on the result. Every turn is a chance for the model to redraw something you never mentioned. The 2.5 generation improved instruction following across turns, and Sunburst is the model to spend that improvement on. A four turn edit chain on the fast model can quietly undo your first three instructions.

The inverse rule is just as useful. If nobody inspects the output closely, Flare is the right call. Mood boards, layout placeholders, blog headers, internal decks, and social variants do not need the slower model. Neither do the fifty runs you make while tuning a prompt. Tune on Flare, ship the final on whichever model your comparison favors.

A last heuristic for the undecided. If you cannot describe what would make you reject an image, you do not need Sunburst. Precision only pays when you hold a precise standard. Teams that route everything to the slower model usually discover they added latency without changing a single approval decision.

Treat the model id as configuration, never as a literal buried inside a helper function. One environment variable plus one per job override gives you everything you need. You can move a whole workload to the other model without shipping code, and you can test the change on a slice of traffic before committing to it.

Default to Flare and make Sunburst opt in. Opt in beats opt out here, because the slower model raises your latency budget quietly. A team that defaults to precision often ships a sluggish product and never traces the cause. A team that defaults to speed hears complaints only from the jobs that genuinely needed precision, which is exactly the signal you want.

Log the model id next to every generated asset. When a client rejects an image six weeks later, you want to know which model produced it, at which quality tier, and from which prompt. Image work gets reviewed by humans on a slow loop, so that trace matters more here than it does for text generation.

Plan retries deliberately. Falling back from Sunburst to Flare after a timeout is sensible for a draft and wrong for a final asset. Decide which jobs may downgrade silently and which must fail loudly instead. That decision belongs in your queue configuration, not in an exception handler somebody wrote at midnight under pressure.

Three claims about these two models circulate widely. All three are wrong, and each one leads to a bad production decision.

The first is that Sunburst costs more. It does not. Text input, image input, and image output bill at the same rates on both models. Those rates also match GPT Image 2, so moving up a generation adds nothing to your unit economics. Your bill moves when you change the quality setting or the output size, because both change how many image tokens a single request produces. The model name is not a cost lever.

The second is that Sunburst is a higher resolution model. It is not. Both models expose the same six quality settings and serve the same two endpoints. Detail comes from the quality tier and the size you request, not from which sibling you called. If your output looks soft on Flare, raise the quality tier before you switch models. Switching for sharpness is a category error and it will cost you latency without fixing anything.

The third is that Flare is GPT Image 2 under a new label. It is not. Flare belongs to the 2.5 generation. It runs faster than Images 2.0, it records a lower unsafe generation rate, and it carries the same lighting, texture, and reference preservation improvements the release introduced. Treating it as a rename means you will skip a migration that costs one string and delivers real gains.

A fourth confusion is worth heading off before it reaches your planning documents. Microsoft ships a model called MAI-Image-2.5. Different vendor, different product, coincidental version number. Search results blend the two constantly and so do secondhand summaries. Check the vendor before you copy any price, limit, or benchmark figure into a spreadsheet.