GPT-Image-2.6 vs GPT-Image-2.5: The Swap Is One String, the Invoice Isn't

Migrating from GPT-Image-2.5 to GPT-Image-2.6 is, at the API level, the least dramatic upgrade OpenAI has shipped all year. Same two endpoints, same rate card, same Flare-versus-Sunburst split. The model string changes and nothing else has to. That is also the trap. GPT-Image-2.6 adds one parameter that GPT-Image-2.5 never had — a complexity dial — and leaving it out does not switch it off. It defaults to high. A pipeline that swaps the string and ships is not buying the same amount of work for the same amount of money; it is buying more work, which is why the first cost report after a migration can move even though the published rates did not.

Both models went general availability on the same commercial terms, and that is what makes this comparison unusual. There is no pricing argument to have. The argument is entirely about where the new work gets spent, and whether your traffic is shaped so that it benefits.

The API surface really is a drop-in — with one hole in it

OpenAI shipped GPT-Image-2.6 on 4 November 2026 as two API models rather than one, inheriting the structure it established with 2.5. The detail- and consistency-oriented tier is GPT-Image-2.6 Sunburst; the speed tier is GPT-Image-2.6 Flare. Their predecessors, GPT-Image-2.5 Sunburst and GPT-Image-2.5 Flare, keep the same names and the same relationship to each other.

• Model strings — gpt-image-2.6-flare and gpt-image-2.6-sunburst replace gpt-image-2.5-flare and gpt-image-2.5-sunburst, same naming logic, one for latency and one for detail.

• Endpoints — /v1/images/generations and /v1/images/edits, unchanged. No new endpoint to integrate.

• Rates — $5 per million text input tokens, $8 per million image input tokens, $30 per million image output tokens, with cached input at $1.25 and $2.00. Byte-for-byte identical to 2.5.

• Quality tiers — low, medium, high, xhigh, max and auto. Same ladder.

• Recommended sizes — 1024×1024, 1536×1024 and 1024×1536 still lead the documentation, with custom dimensions accepted in multiples of 16 and aspect ratios from 1:3 to 3:1.

• The hole — 2.6 is not available through the Batch API. If a nightly job at half price is how your image spend works, that job does not move yet.

That last line is the one that actually breaks something. Everything above it is a string replace and a regression run. The batch gap is an architectural blocker for exactly the workloads — bulk catalogues, nightly backfills, large-scale A/B generation — where a 50% discount is the reason the workload exists at all.

The complexity dial is the real feature, and its default is the surprise

Complexity is a new axis that sits alongside quality rather than inside it, and the distinction matters more than it sounds. Quality controls the render: how many output tokens go into the picture. Complexity controls the planning: how much reasoning the model does before it starts rendering. You can ask for a low-quality image of a complicated scene, or a high-quality image of a simple one, and in 2.6 those are genuinely separate requests.

The documentation is explicit that omitting the parameter defaults it to high. So a caller who ports a 2.5 request by changing the model name and nothing else is silently opting into the maximum planning budget on every call. That is not a bug — it is the sensible default for a model whose selling point is doing more thinking — but it does mean the first month of 2.6 traffic is not a like-for-like comparison with the last month of 2.5 traffic.

There is at least one public data point pointing the same way. A three-image hands-on test published on 4 November reported $0.1245 of 2.6 output against $0.0446 for the same stills on 2.5 — roughly triple, on a rate card that did not change. Three images is not a benchmark and should not be quoted as one; the sample is far too small to establish a multiplier. What it does do is demonstrate the mechanism, and the mechanism is documented: more planning tokens per request, on by default, billed at $30 per million.

If you take one operational step from this article, take this one. Set complexity explicitly — medium is a reasonable first guess for matching 2.5-era behaviour — and then measure output tokens per request before and after. Do not measure dollars per request. Dollars per request will tell you the rate card did not change, which you already knew. Tokens per request will tell you whether the model is doing more work than you asked for.

Where the claimed 50% speed-up actually lands

OpenAI describes GPT-Image-2.6 as roughly 50% faster overall, but the per-tier figures are much more interesting than the headline, and they are the vendor's own numbers, not independently measured. Flare is reported at about 2.6× its predecessor, with low-quality renders completing in as little as six seconds. Sunburst is reported at about 1.15×.

Those two numbers describe two completely different upgrades. If your pipeline runs Flare for iteration — thumbnail exploration, prompt tuning, anything where a human is waiting on the result — 2.6 is a step change and the migration pays for itself in attention alone. If your pipeline runs Sunburst for final output quality, a 15% latency improvement is within the range of run-to-run noise on most hosting setups, and speed is not a reason to migrate at all.

Worth flagging honestly: the same small hands-on test that reported the token inflation also reported 2.6 as slower than 2.5 on its three images, which contradicts the vendor claim. With n=3 that is noise, not a refutation. But it is a reminder that "50% faster" is a launch-deck aggregate across quality tiers and a real pipeline sees one tier at one quality setting.

Nobody has scored 2.6 yet, and 2.5 is still first

This is the part of the comparison that most coverage is glossing over. Artificial Analysis, running its AA-Image-T2I v2.1 and editing boards, had no row for GPT-Image-2.6 at all when read on 5 November 2026. Not a low score — no row.

What those boards do show is that the model being replaced is still winning them:

• Text-to-image — GPT-Image-2.5 Sunburst (max) 1,224 Elo from 13,153 votes, first. GPT-Image-2.5 Flare (max) 1,207 from 12,498, second. GPT Image 2 (high) 1,188, third.

• Image editing — GPT-Image-2.5 Sunburst (max) 1,200 from 18,370 votes, first. GPT-Image-2.5 Flare (max) 1,183 from 19,259, third behind MAI-Image-2.7-Preview at 1,197.

OpenAI's launch material cites Design Arena for a first-place placing for 2.6 Sunburst. That is a real claim on a real board, but it is a different rater pool on a different scale, and a vendor picking the board that flatters its release is not evidence of anything a buyer can use. The comparable, third-party, voted number for 2.6 does not exist yet. Until it does, the defensible position is that 2.5 is the highest independently scored image model on both major boards and 2.6 is unproven — better in the specific ways OpenAI says it is better, and unmeasured everywhere else.

A migration that fits in an afternoon

The swap is cheap enough that the sensible approach is not a big-bang migration but a measured one, run on your own prompts rather than on anyone's benchmark prompt set.

Start by pinning complexity to a value you chose, so the change is a change you made rather than one that arrived by default. Then re-run a couple of hundred real prompts from your production logs — not the clean prompts in your test fixtures, the messy ones with the typos and the awkward aspect ratios. Compare two numbers: output tokens per accepted image, and accepted images per hundred attempts. The second one is where a consistency improvement would show up, and it is the number that actually determines whether the upgrade saves money, because an image you throw away costs the full token budget and returns nothing.

Keep a fallback path to 2.5 for batch work, since 2.6 cannot serve it yet. And treat any Sunburst traffic as a quality question rather than a speed one — if the accept rate does not move, you have bought a 15% latency improvement and a larger planning bill.

When staying on 2.5 is the right answer

Three cases are clear enough to name. Batch workloads should stay, because 2.6 is not on the Batch API and 2.5 is. Sunburst quality pipelines should stay unless the accept-rate test says otherwise, because a 1.15× speed-up does not pay for a cost-model change. And anyone whose current accept rate is already acceptable should stay, because the new capabilities — SVG export, animated GIF, markup-guided editing — are additive features, not quality improvements, and you only need them if you have a deliverable that requires them.

The upgrade is a genuine one. It is just concentrated in Flare latency and in new output formats, and those are narrower than "a new model" implies.

Availability, and the awkward shape of a split migration

OrcaRouter carries GPT-Image-2.5 Flare and GPT-Image-2.5 Sunburst today at list price with 0% markup, so the provider's rate is the rate you pay with no margin layered on top. GPT-Image-2.6 is not in the catalogue as of 5 November 2026 — a day after launch — which makes the immediate practical problem a routing one rather than a modelling one: during the bake-off, 2.5 traffic runs on one key with automatic failover while 2.6 traffic goes direct to OpenAI under a second contract and a second bill.

That split is worth planning around rather than discovering. Check the catalogue before you commit a production path to 2.6, because launch-day parity is not something any router can promise on a model that is twenty-four hours old. When it does land, the pass-through rule means the vendor's rate is what you pay the same day — a price change on OpenAI's side would arrive without a renegotiation on ours — but until then, the honest reading of the situation is that 2.5 is routable and 2.6 is not.

Which is another argument for the afternoon-sized migration over the weekend-sized one. Run 2.5 through the router, keep your cost baseline stable, and add 2.6 behind a flag once you have measured what the complexity default does to your token counts. The model is not going anywhere, and the batch endpoint will arrive before your next quarterly planning cycle does.