GPT-Image-2.5: The Reference Page for OpenAI's Split Image Model

There is no model called gpt-image-2.5. If you paste that string into the vendor's API, you get an error, because the model ID does not exist — and if you open the API documentation at the address that would hold it, you get a 404. What exists is a pair: GPT-Image-2.5 Sunburst, whose identifier is gpt-image-2.5-sunburst and which the vendor describes as "our most capable model for image generation and editing," and GPT-Image-2.5 Flare, whose identifier is gpt-image-2.5-flare and which the vendor describes as "fast, high-quality everyday image generation." Both are the successor generation to GPT-Image-2, and the entire two-model arrangement is the single most important thing to understand before you write a line of code against either one. That naming gap is also why this page exists: the question people type — "gpt image 2.5" — has no dedicated answer here, only partial ones scattered across variant and comparison pieces.

Everything in this reference is read off the vendor's own API documentation on 2026-10-12, plus one independent leaderboard capture from the same day. Where the vendor publishes nothing, this page says so rather than filling the gap. Where the vendor's own pages disagree with each other, this page says that too.

What GPT-Image-2.5 is, and how it sits on GPT-Image-2

GPT-Image-2.5 is the third generation of the vendor's token-metered image family and the direct successor to GPT-Image-2, whose single API snapshot is dated gpt-image-2-2026-04-21. The 2.5 generation arrived in the API on 2026-09-08 — both variants carry that date in their default snapshot names, gpt-image-2.5-sunburst-2026-09-08 and gpt-image-2.5-flare-2026-09-08. That is the launch date on the vendor's own record, and it is roughly four and a half months after GPT-Image-2. The model is not new this week; what follows is the standing reference, not a launch notice.

The generational change is not a single model with a bigger version number. It is a fork. Every earlier GPT-Image generation shipped one primary model ID — GPT-Image-1, then GPT-Image-1.5, then gpt-image-2 — and you selected a quality tier inside that one model. With 2.5, the vendor ships two separately named, separately snapshotted models and asks you to pick which one your workload belongs to. There is no umbrella model that dispatches to both.

Three practical consequences follow from that, and they are worth stating plainly because they are what a reader searching the model's name actually needs:

• There is no gpt-image-2.5 alias. Code written against a hypothetical bare name will not run; you must name gpt-image-2.5-sunburst or gpt-image-2.5-flare explicitly.

• The two variants share a price sheet and a rate-limit schedule, so your choice between them is a latency-and-precision decision, not a budget decision. the vendor's own framing of the split is a workload split, not a quality ladder you climb by paying more.

• "GPT-Image-2.5" without a suffix is a generation name, not a model. When you see it in a changelog, a bill, or a product announcement, it means the generation, and you still have to know which of the two models produced the work.

Flare or Sunburst: how to choose

This is the question the model's own name keeps generating, and the variant vocabulary is counterintuitive enough that a lot of people ask it in both directions before they find an answer. Here it is settled, one line per variant, on the vendor's published positioning rather than on inference from benchmarks:

• Flare — gpt-image-2.5-flare, snapshot gpt-image-2.5-flare-2026-09-08. Pick it when throughput and turnaround are the constraint: everyday image generation, high-volume pipelines, prototypes, social and product visuals, anything where "good, now" beats "better, eventually." It is the model the vendor labels as the fast, high-quality everyday option, and it is the one to make your default call.

• Sunburst — gpt-image-2.5-sunburst, snapshot gpt-image-2.5-sunburst-2026-09-08. Pick it when the edit itself is the deliverable and precision matters more than latency: iterated edits where a change made in turn two has to survive turn three, layout-sensitive compositions, masked inpainting that has to land where you aimed it. the vendor's image-generation guide gives the split in one sentence: "Choose Sunburst for workflows where editing precision matters most, and Flare for fast, high-quality everyday image generation."

The honest caveat: the vendor does not publish a latency figure, a per-image cost, or a quality benchmark that quantifies the gap between the two, so "slower" and "more precise" are the vendor's characterisation, not a measured ratio. The one independent board that carries both models does separate them, and it agrees on the ordering — see the evidence section below. What it does not do is give you a matched-harness, matched-effort head-to-head with a confidence interval you could put in a capacity plan. Nobody has published that.

A workable default if you would rather not think about it: call Flare everywhere, and route to Sunburst on the specific requests where an edit has to hold — the ones carrying a mask, or a reference subject you need to keep stable across turns. That is exactly the "unproven model, don't bet the production path on it" shape where routing a single endpoint across both is cheaper than committing to one.

What it accepts and what it returns

Both variants declare the same modality envelope on the vendor's model pages. Input: text and image. Output: image. Text output is not produced, and the vendor's pricing notes confirm the consequence — text output is not billed, because the model does not return any.

The size envelope is wider than the three presets suggest:

• Recommended presets — 1024×1024 square, 1536×1024 landscape, 1024×1536 portrait.

• Custom dimensions — both models accept arbitrary WIDTHxHEIGHT strings, with three constraints stated verbatim in the guide: width and height must be multiples of 16; the aspect ratio must sit between 1:3 and 3:1; and neither edge may exceed 3840 pixels.

• Total pixel budget — between 655,360 and 8,294,400 pixels, which the vendor glosses as 4K at the ceiling.

• Experimental zone — resolutions above 2560×1440 are flagged as experimental by the vendor. Treat anything past that as unvalidated for production.

Output format defaults to PNG, with JPEG and WebP available. Compression is controllable through an output_compression parameter on a 0–100 scale, and the vendor notes that JPEG is faster than PNG — worth knowing if latency is why you picked Flare in the first place. Transparent backgrounds require background: "transparent" paired with a PNG or WebP output format. The API returns base64-encoded image data.

Quality selection runs low, medium, high, xhigh, max, and auto. The two 2.5 models are the ones that add xhigh and max; earlier GPT Image models cap at high. Both 2.5 variants default to auto. If the tiers read as a second quality axis stacked on top of the Flare/Sunburst choice, that is because they are one: you pick a variant and then a tier, and the two compound on both latency and cost.

Rate limits are identical for both models and are given by usage tier as tokens and images per minute: Build 250,000 / 20, Launch 3,000,000 / 150, Grow 8,000,000 / 250. The same schedule is listed for gpt-image-2. the vendor also notes that using these models may require completing API Organization Verification.

The endpoint surface, and a documentation conflict

This is the section where re-reading the vendor's material matters, because the vendor's own pages do not fully agree.

The model pages for gpt-image-2.5-sunburst and gpt-image-2.5-flare list exactly three supported endpoints: v1/images/generations, v1/images/edits, and v1/batch. Everything else in the table is marked not supported — including v1/responses and v1/chat/completions. This is the same three-endpoint surface GPT-Image-2 exposes, and it means the Chat Completions shape you may have used for an earlier image model will not carry over.

The image-generation guide, however, describes a Responses API path in which you select a mainline model and name the image model inside a tool field, and the pricing page's notes say cached input rates for GPT-Image-2 and 2.5 "apply only to Responses API generations." Those two statements imply a Responses surface that the model page explicitly marks unsupported. The guide's own worked examples pair the image tool with gpt-6-astra as the mainline model.

I am reporting the conflict rather than resolving it. The conservative reading — and the one to build against — is the model page: generations, edits, batch. Test the Responses path against your own account before you depend on it, because the page that would authorise it currently says no.

Text rendering and editing behaviour

Editing is where the 2.5 generation is aimed, and the documentation is unusually specific about the mechanics and the limits.

The edits endpoint handles inpainting — the only editing feature listed on either model page. You upload an image plus a mask identifying the region to replace. Two constraints matter more than they look. First, masking with these models is entirely prompt-based: the model uses the mask as guidance and, in the vendor's wording, "may not follow its exact shape with complete precision." Second, the image and the mask must be the same format and size and under 50MB, and the mask must carry an alpha channel — a plain black-and-white mask will not work until you add one programmatically. If you supply multiple input images, the mask applies to the first.

On text, the honest line comes from the vendor's own limitations list, not from a vendor marketing claim: "Although significantly improved, the model can still struggle with precise text placement and clarity." Read that literally. This generation renders text better than its predecessors and is still not a layout engine. The same limitations list adds that complex prompts can take up to two minutes to process, that the model may struggle to keep recurring characters or brand elements visually consistent, and that it can have difficulty placing elements precisely in structured or layout-sensitive compositions. Every one of those is a direct argument for Sunburst on layout work and against assuming either variant will hold a template.

Moderation applies to both: the vendor states that all prompts and generated images are filtered against its content policy, with a moderation parameter offering auto (the default) or low, and blocked requests returning an error code of moderation_blocked with optional detail.

Licence and usage terms as published

the vendor's published model and image-generation documentation does not carry the output-ownership and commercial-use clauses; those live in its separate terms, which are not reproduced in the developer docs. What the developer documentation does state, in its data-handling guide, is that API data is not used for training unless you opt in, and the guide's table lists "used for training: No" for the /v1/images/generations and /v1/images/edits endpoints. Image generation is also described there as Zero Data Retention compatible for the specific model names listed on that page.

Nothing in the API documentation grants or describes a free tier, free credits, a trial allowance, or a rate-limit exemption for either 2.5 model. There is no published free allowance to point at. What is published is a price, and it is the same one GPT-Image-2 already carried — see the next section.

Pricing, and the fact that it did not move

the vendor publishes no per-image price for either 2.5 variant. Pricing is metered in tokens, per million, and the rates are identical across the two models and identical to GPT-Image-2:

• Standard, text input — $5.00 per 1M tokens; cached text input $1.25.

• Standard, image input — $8.00 per 1M tokens; cached image input $2.00.

• Standard, image output — $30.00 per 1M tokens.

• Batch, text input — $2.50; image input $4.00; image output $15.00, with cached rates correspondingly halved.

Two things about that sheet are worth more than the numbers themselves. First, the 2.5 generation did not raise the price: gpt-image-2 lists $8 in and $30 out on the image side and $5 on text, exactly as 2.5 does. For contrast, GPT-Image-1.5 sits at $8 in and $32 out with a $10 text-output rate, and GPT-Image-1 at $10 in and $40 out. The 2.5 upgrade is a capability-and-latency change at an unchanged rate card. Second, the vendor notes that its existing image-generation cost calculator does not estimate 2.5 usage, so you should not project spend for these models from tooling built for the older generation. The vendor publishes no per-image figure, so any per-image number you see quoted for these models is somebody else's conversion, not the vendor's.

Because the price is passed through at provider list with no markup added on our side, those rates are what you pay on OrcaRouter, and a vendor rate change lands the same day. Both models are in our live catalogue today. I checked, since an availability claim from an older page is exactly the kind of thing that goes stale: gpt-image-2.5-sunburst and gpt-image-2.5-flare are both routable through the same OpenAI-compatible endpoint as everything else, at the $8 in / $30 out image rates above. If you are evaluating the pair rather than committing to one, that matters for a practical reason — a single key and a routing rule let you send a class of requests to Sunburst and everything else to Flare, and change the split without a second contract or a code change.

What independent testing says, and what nobody has measured

the vendor publishes no benchmark scores for either variant on its model pages. The independent evidence is thinner than the launch coverage implied, and it is worth being precise about what it does and does not show.

Artificial Analysis maintains text-to-image boards covering both a quality-Elo ranking and a representative API price per 1,000 generated images. On the capture taken on 2026-10-12, both GPT Image 2.5 Sunburst (max) and GPT Image 2.5 Flare (max) appear as high-placed entries, with Sunburst ordered above Flare, and both placed above GPT Image 2 (high). I am deliberately not printing Elo values from that capture: the board renders its per-model figures graphically and the individual labels were not cleanly extractable from the page as captured, so a number quoted here would be a reading of a chart rather than of the data behind it. If you need the figure, go to the board.

That price axis is also the only place a per-image-equivalent figure for these models currently exists — Artificial Analysis derives a representative cost per 1,000 images from token-metered pricing. It is an independent estimate produced by a third party's methodology, not a vendor rate, and the vendor itself publishes no per-image figure at all. Use it to compare shapes of cost across models; do not quote it as the vendor's price.

What follows from that evidence, honestly stated: the ordering of the two variants is corroborated independently, which is the part that matters for the Flare-or-Sunburst decision. What is not established is any comparison between a 2.5 variant and a competing image model measured at matched effort and on a matched harness. The board's entries are tiered — "Sunburst (max)" and "Flare (max)" name the quality setting, and other models on the same board are listed at their own tiers, not at a common one. A ranking across tier labels is not a ranking at equal settings, and treating it as one would overstate what has actually been tested.

Where this leaves you

If you arrived here with the model's name and nothing else, the operative facts are these. Ask for gpt-image-2.5-sunburst or gpt-image-2.5-flare; there is no third option and no bare alias. Both take text and images and return an image, up to a 3840-pixel edge and 8,294,400 total pixels, from one of three endpoints. Flare is the throughput choice, Sunburst the precision choice, and the vendor's own docs admit the mask is guidance rather than a hard boundary, so neither will give you a perfectly deterministic edit. The rate card is unchanged from GPT-Image-2 at $8 per million image input tokens and $30 per million image output tokens, with batch at half, and no per-image price or free allowance exists on the vendor's page to compare against.

What is still genuinely open is the thing a capacity plan wants most: a measured latency difference and a matched-harness quality comparison between the two variants. Until someone publishes those, the split between Flare and Sunburst is a design decision on the vendor's stated positioning plus one leaderboard's ordering — which is more than most launches give you, and less than a benchmark would.