An image job can finish after the user has changed the brief. For a GPT Image 2.5 integration, accepting that late result as current would attach a valid image to the wrong request. Bind each request and every accepted event to an application-owned job revision before starting it.
The upstream image-generation guide, captured on 9 September 2026, documents partial_images values from 0 to 3. Zero requests only the final image; positive values may produce fewer partials than requested if generation finishes sooner. Its Image API example uses gpt-image-2.5-sunburst, stream: true, and partial_images: 2, then handles image_generation.partial_image with partial_image_index and b64_json. A count of partials is therefore unsuitable as the completion signal.
Put the CometAPI adapter behind an explicit check
CometAPI’s GPT Image 2.5 page documents gpt-image-2.5-sunburst at https://api.cometapi.com/v1/images/generations. That binds the model and route to check. Its sample does not establish that this route forwards the upstream streaming fields, event names or cancellation behavior.
For this CometAPI integration, I would keep partial-event handling disabled until the adapter has verified the selected route’s acceptance of stream and partial_images, its partial payloads, and its terminal success/error signals. If only ordinary generation is verified, retain the same revision check when its final response arrives. Do not assume that changing the base URL turns the upstream streaming example into a verified gateway contract.
The following is a proposed application policy, not a record of executed CometAPI tests. “Partial” and “final” describe normalized application events; the adapter must map them from the route’s verified response format.
| Request or event | Rule for the current job revision | If the revision has been superseded |
|---|---|---|
partial_images: 0 |
Expect no partials on a successful upstream stream; wait for terminal success or failure | Suppress the late result from the current brief |
partial_images: 1 |
Accept an available partial provisionally; do not require one before terminal success | Ignore its partial and terminal events for current state |
partial_images: 2 |
Accept available partials; terminal success remains valid with fewer than two | Apply the same stale-revision check |
partial_images: 3 |
Accept available partials; do not wait for a third after terminal success | Apply the same stale-revision check |
| Final arrives after fewer partials than requested | Complete only this current revision; stop waiting for missing partials | Keep it out of the replacement revision |
| User interrupts locally | Mark the revision inactive immediately, before starting replacement work | Suppress subsequent events even if the remote request continues |
Store the job ID and revision in local request context; do not invent an API parameter or expect the provider to echo them. Before mutating application state, compare the event’s locally bound revision with the current revision. Make the comparison and update one serialized operation so an interruption cannot slip between them. After a revision is terminal, ignore any later partial that would reopen it.
For example, a voice application could turn an updated spoken brief into a new text prompt and revision. The image stage remains separate: this design does not require or imply audio input support from GPT Image 2.5. A final image belonging to the old brief stays old even if it arrives after the replacement request starts.
Local suppression establishes only what the application accepts. It does not prove that CometAPI or the upstream provider cancelled generation, stopped billing, or released resources. Record any remote cancellation outcome separately if that capability is later verified. The proposed acceptance check is straightforward: an obsolete partial or final must never change the current revision, while a current final must not wait for an unfulfilled partial count.