The fastest way to get a disappointing AI image is to ask for one perfect result. The second fastest is to send one reference photo and expect the model to understand which part matters. A face, a product, a room layout, a color palette, and a pose are different kinds of information. They should not have to fight for space inside one image.

GPT Image 2.5 makes a better workflow possible, but the useful change is not simply that the pictures look nicer. OpenAI released two API models with different jobs. Flare is the sensible default for fast, repeated generation. Sunburst is the slower choice when you need tighter control across edits. OpenAI says Flare cuts latency by up to 50% compared with Images 2.0. That matters when you are testing ten variations instead of admiring one demo.

The model is already operating at large scale. OpenAI says its image systems handle more than 3 billion images weekly across ChatGPT Images and the API. That number does not prove quality, but it tells you the intended product shape: image generation is becoming an iterative production step, not a novelty button.

GPT Image 2.5 reference-led image workflow

The reference image pipeline

Start by splitting the job into three inputs: identity, composition, and change. Identity is the thing that must survive the edit, such as a person, a product package, or a specific room. Composition describes where the subject sits and what the camera should preserve. Change is the one thing you want to alter. If the prompt contains five changes, you will not know which instruction caused the drift.

Use Flare when the output is a draft, a social variant, a product thumbnail, or one of many options. Use Sunburst when the image is close and you need a controlled edit, such as changing a label, replacing a background object, or preserving a recognizable subject through several revisions. This is not a quality ranking. It is a queueing rule. Spend the slower model after you know what you want.

The official API documentation shows an edit request with 4 reference images. That is a useful pattern even when you only have two files. Give each image a role. One can establish the product shape. Another can establish the surface or material. A third can show the desired composition. A fourth can provide a logo or package detail. Then state which reference controls which property.

The request shape looks like this in the OpenAI CLI:

openai images edit \
  --model gpt-image-2.5-sunburst \
  --image product.png \
  --image package-detail.png \
  --image shelf-layout.png \
  --prompt "Keep the product shape from product.png and the label layout from package-detail.png. Place it in the shelf composition from shelf-layout.png. Change only the background to a warm studio gradient. Preserve the logo, proportions, and camera angle." \
  --raw-output \
  --transform 'data.0.b64_json' | base64 --decode > edited.png

The command is less important than the separation of roles. A reference image is evidence, not a complete instruction. Name the file's job in the prompt. Say what must remain unchanged. Say what is allowed to move. Ask for one edit.

For a multi-turn workflow, save every accepted output with the prompt that produced it. On the next turn, pass the latest image and describe only the next correction. Do not keep reintroducing the entire art direction unless the model has lost it. Repetition makes the request harder to diagnose, and it can encourage the system to reinterpret details that were already correct.

That is the practical difference between generation and editing. Generation asks the model to decide almost everything. Editing gives it a stable state and a narrow delta. The second approach is easier to review, easier to retry, and much easier to automate. If you have been reading our earlier ChatGPT Images 2.0 breakdown, treat this as the operational follow-up rather than another feature tour.

Where the workflow breaks

The first failure is reference overload. Four images are useful when each image supplies a different constraint. Four images are noise when all four show the same subject from slightly different angles. Start with two. Add another only when you can explain what new information it supplies.

The second failure is an ambiguous preservation request. “Keep everything the same” is not an instruction a vision model can verify by itself. Write a short preservation list: subject identity, silhouette, logo placement, camera angle, and crop. Then name the single permitted change. This also gives a human reviewer a checklist.

The third failure is using Sunburst for exploration. The premium precision model cannot rescue an unclear brief. Generate rough options with Flare, choose one, then switch to Sunburst for the final edits. OpenAI describes Flare as the default for most applications and Sunburst as the choice for detailed creative work with longer generation times. The split is practical, especially when a team is paying for every iteration.

The fourth failure is pretending that multi-turn consistency means perfect consistency. OpenAI says Images 2.5 is better at carrying earlier changes forward, not that it will preserve every pixel. Keep the original reference files. Compare the new output against the previous accepted version. If a logo, face, or product dimension matters, use an external check or a human approval step instead of trusting the visual impression.

The fifth failure is forgetting input cost. GPT Image models can charge for image input as well as generated output, and the official guide says reference images are processed at high fidelity for GPT Image 2. More references can mean more useful context, but they can also increase the bill and the request size. Log the model, number of references, quality, resolution, latency, and whether the edit passed review. After twenty or thirty runs, you will have a real cost model instead of a guess.

A small production loop is enough:

  1. Generate three rough directions with Flare.
  2. Select one and record the prompt plus reference files.
  3. Make one narrow edit with Sunburst.
  4. Check identity, composition, text, and the requested change.
  5. Accept, revise, or return to the rough stage.

Do not call every failed image a prompt failure. Sometimes the source image lacks the information you want to preserve. Sometimes the requested change is not local enough. Sometimes the model is simply wrong. The point of the pipeline is to make those cases visible and cheap to repeat.

The good news is that the workflow does not require a complicated image editor. It requires better bookkeeping. Give references distinct roles, keep edits narrow, use the fast model for search, and reserve the slower model for decisions you are ready to keep. That is a much more reliable way to use GPT Image 2.5 than hunting for a magic sentence.

Sources