The GPT Image 2.6 pricing page looks reassuringly simple. Flare and Sunburst are priced the same, with image output at $30 per million tokens, image input at $8 and text input at $5, just like 2.5.
Before upgrading, though, developers should work through a few numbers.
Same unit price, not necessarily the same price per image
On the OpenAI developer community forum, one developer posted a side-by-side sample using an identical prompt: at medium quality, 2.5 produced 344 output tokens and 2.6 produced 1,136.
At $30 per million tokens, that is a rough jump in output cost per image from about 1 cent to about 3.4 cents, a 3.3x increase on that line item alone. The developer estimates the multiple is even higher at the low tier, around 4.2x, while at high and above the two are roughly level.
This is a personal sample and a back-of-the-envelope estimate, and OpenAI has not published comparable figures. What it does show is that the price list alone is not enough to plan a migration. A practical approach is to run the same set of about 20 prompts through both 2.5 and 2.6, compare output tokens per image, and only then decide whether to switch.
Two things that are missing
Batch. The pages for both 2.6 models list v1/batch as unsupported. 2.5 Flare can still run through Batch, where output is billed at half the standard rate, $15 per million tokens. For a business that renders large numbers of bitmaps in a nightly batch, staying on 2.5 is clearly cheaper.
Pinned snapshots. For now 2.6 only has a default snapshot, while 2.5 offers dated versions such as gpt-image-2.5-flare-2026-09-08. For production workloads that depend on stable output, that belongs in the risk assessment.
How the new parameter works
The new complexity parameter has three levels, low, medium and high, and controls how much planning the model does before rendering. It defaults to high when omitted, and changing it carries no extra charge.
That high default is easy to overlook. The official documentation is explicit: lower values suit focused edits such as swapping a background, while higher values help with dense text and complex layouts but may add latency and can introduce unwanted changes. For endpoints that do local edits, it is wise to pass low explicitly as a starting point.
The limits on the other new capabilities are collected here:
| Capability | Usage | Limits |
|---|---|---|
| SVG | output_format: "svg" on the generation endpoint | n must be 1; no streaming or partial images; the edit endpoint cannot output SVG |
| GIF | output_format: "gif" with frame_count and frame_duration_ms | Defaults to 9 frames at 200 ms each; the documentation gives two different frame caps, 64 and 16 |
| Markup editing | POST /v1/images/edits with a transparent PNG annotation layer | Width and height must match the original image; cannot be combined with mask or prompt_rewriter |
Also, using GPT Image models may require completing organization verification first, so new accounts should leave time for that step.
How to read the speed and quality claims
“50% faster” and “as fast as about 6 seconds” are both OpenAI's own claims. One report points out that the 6-second figure corresponds to Flare at its low quality setting, and the baseline and measurement method behind the 50% have not been published.
Independent data is still thin. According to third-party compilations, on Arena's preliminary leaderboard of November 4, Sunburst scored 1409 in text-to-image and ranked second, while Flare scored 1384 and ranked fourth, both at the medium configuration; Artificial Analysis had no entry for 2.6 at the time. These rankings may shift within a few weeks, so treat them as a reference only when choosing a model.
We also wanted to test native GIF output, but the image generation tool built into the local Codex does not expose model or output-format parameters. A direct request returned only a single-frame PNG, and we could not confirm which model version was behind it. The loading animation on this page therefore had to be assembled from a six-frame sprite sheet. The first version had an uneven path and was redrawn once, and the circling trajectory still drifts slightly.
For small animations in a product, the API's GIF parameters or hand-written CSS animation are both more controllable than this route. A sprite sheet is good enough for editorial illustrations but not yet precise enough for interface assets.
Which option fits which case
- Nightly batch image generation: stay on 2.5 for now and take the half-price Batch rate.
- Need vector icons or short looping animations: these are new in 2.6, so you can migrate for them alone.
- Online editing features: before moving to Sunburst or Flare, log output tokens per image for a week and set
complexityandqualityexplicitly. - Designers and operations staff on the team need it: they do not necessarily have to wait for an API slot.
The last case is a common one. Engineering is still running comparisons and waiting on organization verification, while the operations team needs campaign images next week. In the meantime they can use a ready-made workspace such as pixpix.com/gpt-image-2-6, where both Flare and Sunburst can be selected and which works after login, with reference images and model settings inside the workspace. It bills in credits, and the actual consumption has to be checked in the workspace; the model page lists no prices and does not mention GIF or SVG. So it solves getting static images going first, and integrating into a product still means going through the API.
If operations runs through a batch of real requests and prompts first, engineering will have a ready-made test set when it compares 2.5 and 2.6, which is closer to production than inventing 20 prompts from scratch.
Sources: OpenAI model pages and image generation documentation, OpenAI developer community, CocoLoop, DEV Community, Kingy AI, Digit; community token figures are a personal sample, and costs are our own rough calculation.