If you are adding GPT Image 2.5 to an agent application, decide first whether it is the image executor or the workflow controller. For the Sunburst variant described on CometAPI’s model page, the documented boundary supports the former—not replacing your conversation and tool-orchestration layer.
This reading uses the page captured on September 14, 2026. It identifies Sunburst as part of the GPT Image 2.5 family and gives the API model ID gpt-image-2.5-sunburst. The claims below are attributed to that page; they are not independently verified OpenAI specifications, tested API behavior, or conclusions about Flare.
What the Sunburst page actually establishes
| Surface | What the page reports | Architectural implication |
|---|---|---|
| Modalities | Text and image inputs; image output | Treat the result as an image asset, not a conversational answer or workflow plan. |
| Image operations | Generation and editing; POST /v1/images/generations and POST /v1/images/edits |
Give the application an explicit image-operation boundary. |
| Model features | Streaming, function calling, structured outputs and fine-tuning are unsupported | Do not build the controller around those features being available from Sunburst. |
| Other media | Audio and video are unsupported | Keep those requirements outside this component. |
The right-hand column is design inference, not an additional capability claim.
There is a documentation discrepancy worth keeping visible: the condensed capabilities panel lists only text input, while the fuller specifications list text and images, and the image-to-image editing section explicitly describes image input. That fuller description supports planning an editing component, but it does not supply every request parameter or response field.
The page also contains a question about Image API and Responses API access without an answer. An unanswered FAQ heading is not a basis for choosing a Responses API integration.
Keep control outside the image call
My recommendation is to give Sunburst one bounded generation or editing task at a time. Keep conversation history, the selected source asset, tool routing and the decision to continue or stop in application-owned state or a separately qualified orchestration layer.
For an illustrative “change the background, then revise the lighting” workflow:
- Before invocation: resolve which saved image version the user means and turn the current request into a bounded editing instruction. Require clarification if the target asset is ambiguous.
- At the image boundary: invoke the editing surface using its separately verified request contract. Do not expect Sunburst to select the next tool or emit a structured workflow plan.
- After completion: validate the response and inspect the image against the requested change before treating it as the accepted next version. Store the relationship between the source asset, instruction and resulting asset in the application.
- For the next turn: let the controller select the accepted version and decide whether another edit is warranted. Descriptions of iterative image editing do not establish that the image model owns conversation state or autonomously manages the loop.
These are proposed application responsibilities, not a report of an executed system. Unsupported model function calling does not prevent an external orchestrator from invoking Sunburst as a tool. Likewise, “structured outputs unsupported” does not mean the API cannot return a structured response envelope; it means this page does not support relying on the model to generate your structured control output.
“Async ready” is not a streaming contract
The page labels the endpoint response “Async ready” while its limitations section says model streaming is unsupported. Do not collapse those statements into a promise of incremental image delivery.
The label does not specify polling, webhooks, job states or partial-image events. Before designing a progress UI or completion handler around any of those mechanisms, obtain the actual endpoint protocol. Until then, do not make partial-image delivery a prerequisite of the user experience.
The practical decision is narrow: for gpt-image-2.5-sunburst, build around the reported generation/editing surface and keep orchestration elsewhere. Re-evaluate that boundary if verified documentation changes the listed modalities or control features. Another model needs its own capability check; swapping its name into this design is not evidence that the same restrictions apply.