Hey guys, Mr. Technology here.
The OpenAI changelog dated September 8, 2026 published two new image generation models, GPT Image 2.5 Sunburst (gpt-image-2.5-sunburst) and GPT Image 2.5 Flare (gpt-image-2.5-flare), with the snapshot dated 2026-09-08. Both are available through the Image API and as the model field of the Responses API image generation tool. Both add xhigh and max to the quality-setting list, support inpainting as a first-class feature, and ship with a new image-token pricing surface that did not exist before today. This is a documentation comparison — I read the changelog, both model pages, the image generation guide, and the pricing page. I have not run the models.
If you build image agents on the Responses API, this changes your routing math. If you build coding agents, you can skip the article.
From the OpenAI changelog, dated September 8, 2026 (verified verbatim 2026-09-08 20:08 UTC):
"Released GPT Image 2.5 Sunburst and GPT Image 2.5 Flare for image generation and editing through the Image API and the Responses API image generation tool. Use Sunburst for workflows where editing precision matters most, or Flare for fast, high-quality everyday image generation. Both models support the newxhighandmaxquality settings and use GPT Image 2 token rates."
Two distinct model roles, one shared API surface.
Both models accept text and image inputs, output image, and use the same snapshot date 2026-09-08. The supported endpoints are listed as v1/images/generations and v1/images/edits only. Chat Completions, Responses, Realtime, Batch, Fine-tuning, and Embeddings are explicitly "Not supported" for both models. The v1/images/* routes are the only callable paths.
This is a hard boundary. If your existing agent stack calls image generation through Responses or Chat Completions, you do not call either model directly — you select a supported mainline model at the top level and pass gpt-image-2.5-sunburst or gpt-image-2.5-flare inside the image generation tool's model field. The guide states this explicitly: "With the Responses API, select a supported mainline model at the top level and specify gpt-image-2.5-sunburst or gpt-image-2.5-flare in the image generation tool's model field."
Three concrete changes:
1. The quality-setting ladder widened. The supported quality enum on both models is low, medium, high, xhigh, max, auto. The two new top-of-ladder values are xhigh and max. They replace whatever the previous tier ceiling was — both model pages state the same six-value list, with auto as the default behavior. The OpenAI changelog phrasing is "new xhigh and max quality settings," which is the cleanest statement of capability delta.
2. Inpainting is now a first-class supported feature. Both model pages list inpainting under "Supported features." Inpainting lets you edit a specific region of an input image while preserving the rest. The v1/images/edits endpoint is the route. Previously, inpainting-style workflows required prompt-only edits through the legacy edits endpoint; the model pages now advertise it as supported.
3. The Responses API tool got a real multi-turn editing path. The image generation guide says the Responses API "supports image generation as a built-in tool, and accepts image inputs and outputs within context." Compared to the Image API, it adds two things: multi-turn editing ("Iteratively make high fidelity edits to images with prompting") and flexible inputs ("Accept image File IDs as input images, not just bytes"). For an agent that needs to show a generated image, accept user edits as text, and continue editing across turns, the Responses API tool path is the only documented mechanism that holds the image across turns without re-uploading bytes.
The Responses API integration is the part that matters for agent builders, not the new model names. An agent that wants to produce marketing visuals, product mockups, presentation assets, or design iterations can now:
1. Call the Responses API image generation tool with gpt-image-2.5-flare for a first pass (cheap, fast); 2. Receive the generated image as a File ID in the conversation; 3. Have the model iterate ("make the background dark blue, keep the foreground subject") with the File ID as input; 4. Switch to gpt-image-2.5-sunburst for the final pass at xhigh or max quality.
This is the agent-native image workflow. The guide calls out the two-API split explicitly: "If you only need to generate or edit a single image from one prompt, the Image API is your best choice. If you want to build conversational, editable image experiences with GPT Image, go with the Responses API."
The pricing also matters for routing math. Both models share an identical pricing surface:
| Metric | Price | Unit |
|---|---|---|
| Text input | $5 | 1M tokens |
| Cached text input | $1.25 | 1M tokens |
| Image input | $8 | 1M tokens |
| Cached image input | $2 | 1M tokens |
| Image output | $30 | 1M tokens |
Both model pages state: "Image output costs $30 per million tokens. Text output is not billed because this model outputs images, not text. Token rates match GPT Image 2. The GPT Image 2 calculator does not estimate GPT Image 2.5 token consumption." The last sentence is the practical caveat — there is no working calculator for these models today. Treat token cost estimates as approximate until OpenAI ships a 2.5-specific calculator or a third-party tool catches up.
Primary sources verified at 2026-09-08 20:08 UTC:
gpt-image-2.5-sunburst-2026-09-08, supported features include inpainting): <https://developers.openai.com/api/docs/models/gpt-image-2.5-sunburst>gpt-image-2.5-flare-2026-09-08, supported features include inpainting): <https://developers.openai.com/api/docs/models/gpt-image-2.5-flare>No first-hand test was run. The article is a documentation comparison, not a benchmark or field report.
Cost. The pricing page does not yet list gpt-image-2.5-sunburst or gpt-image-2.5-flare in the Standard / Batch / Flex / Fast tables at the time of fetch (2026-09-08 20:08 UTC). The model pages publish a token rate, but the public pricing page only references "GPT Image 2 token rates" without surfacing the 2.5 models in the visible table. If your billing automation keys off the pricing table rows, the new models may not appear until a subsequent page update. Plan for an offline token-rate estimate using the model-page numbers until the pricing page catches up.
Risk. The image generation guide adds a guardrail: "To ensure these models are used responsibly, you may need to complete the API Organization Verification from your developer console before using GPT Image models." Unverified orgs may be blocked or rate-limited at request time. Verify before you ship to production.
Limitations.
v1/images/generations and v1/images/edits as supported endpoints. There is no v1/responses direct call path; the Responses API integration is tool-mediated.OpenAI shipped two new flagship image generation models with a real Responses API tool integration. The integration is the story — the model names are the wrapper. For builders running image agents on the Responses API, Sunburst and Flare replace whatever image model you were using before today with a wider quality ladder (xhigh, max), explicit inpainting support, and a documented multi-turn editing path. For builders running coding agents, this is a no-op.
The pricing surface is real but immature — token rates exist on the model pages, the public pricing table does not yet surface the 2.5 models in tier rows, and the legacy GPT Image 2 calculator does not estimate 2.5 consumption. Plan for a brief cost-estimation gap.
Today
/api/docs/models/gpt-image-2.5-sunburst, /api/docs/models/gpt-image-2.5-flare) into your model registry and add the new quality enum values (xhigh, max) to any quality-selection UI.This week
gpt-image-2.5-sunburst and gpt-image-2.5-flare rows appear in Standard / Batch / Fast tier tables. Until then, use the model-page token rates and label your cost estimates as approximate.Skip if not in scope