GPT Image 2.5 Flare vs Sunburst: Shared Controls, Different Priorities

Use positioning to select a test, not to declare a result

fal describes Flare as the default choice for many applications and Sunburst as a precision-oriented option that takes longer. That distinction is useful for deciding what to investigate, but it does not settle a particular brief. A description of intended strengths is different from retained output evidence. Neither a speed ratio nor an aesthetic preference from the provider is reproduced here as a DualView finding.

Sources: GPT Image 2.5 family overview and canonical cost examples

Translate the intended use into a rejection rule before reviewing images. An information poster might fail if any required label is wrong, even when the overall composition is attractive. A product illustration might fail if its silhouette becomes ambiguous at its final display size. A surface study might fail if repeated patterns become visibly inconsistent. Those are different decisions; averaging them into an unexplained preference can conceal the failure that matters to your project.

Sources: GPT Image 2.5 family overview and canonical cost examples

Specify a real canvas rather than relying on a size label

Both schemas accept presets, explicit dimensions or automatic sizing. They default to landscape_4_3. The limits in the table apply together: a requested canvas must satisfy the edge, ratio and pixel-area constraints, not just fit below a nominal maximum dimension. For a direct variant comparison, give both the same concrete width and height and inspect the dimensions of the returned files.

Sources: Flare text-to-image input schema · Sunburst text-to-image input schema

Consider a wide banner whose final crop is already specified. If one request uses automatic sizing while another uses a fixed canvas, layout differences could originate in the composition space rather than the model variant. Keep a record of the final crop as well as the generation canvas. Examine whether required text or objects survive the crop. A generous source image can still be unusable if the important content sits outside the delivery region; that is a practical failure, even without an obvious rendering artifact.

Sources: Flare text-to-image input schema · Sunburst text-to-image input schema

Keep quality, transparency and compression as separate choices

The shared quality menu does not promise a particular artistic result. For an initial comparison, select a named level deliberately, and change only that level in a later pass. Likewise, use an explicit background mode when the deliverable needs transparency. The schemas expose output compression for JPEG and WebP; the PNG path does not use that field. A file-format difference can change edge appearance even when generation settings match.

Sources: Flare text-to-image input schema · Sunburst text-to-image input schema

For cutouts, inspect the alpha channel against both light and dark backgrounds rather than judging it only on a checkerboard. Look for fringes, holes and semitransparent remnants around thin structures. For a dense layout, inspect the original file before evaluating a compressed copy. Keep the model output and the delivery conversion separately named. This allows a reviewer to locate whether a defect came from the model, the requested format or a later export, without treating all visible damage as the same cause.

Sources: Flare text-to-image input schema · Sunburst text-to-image input schema

Read token rates alongside the conflicting image examples

On September 26, both endpoint pages list the same USD rates per million tokens: text input $5, cached text $1.25, text output $10; image input $8, cached image $2, image output $30. They say total cost rounds upward to $0.0001. These are provider billing terms, not a fixed per-image tariff or a claim about the direct OpenAI API. Request complexity and prompt length can affect the final amount.

Sources: Flare text-to-image endpoint and token rates · Sunburst text-to-image endpoint and token rates · GPT Image 2.5 family overview and canonical cost examples

For a 1024-square high-quality image, both endpoint tables show $0.05268, while the family overview shows $0.0528. The difference should remain visible instead of being silently reconciled: the reviewed pages do not provide enough detail to reproduce every assumption. Multiplying the endpoint table value by 100 gives $5.268 before accounting for actual request-level billing. It is a planning illustration, not a quote for 100 completed images.

Sources: Flare text-to-image endpoint and token rates · Sunburst text-to-image endpoint and token rates · GPT Image 2.5 family overview and canonical cost examples

For procurement or a production estimate, record the endpoint, canvas, quality, image count and the date of the rate check. Do not interpret a shared rate card as proof that two variants consume identical resources on every request. Nor should a failed attempt disappear from a cost comparison simply because it produced no usable deliverable. Report accepted images separately from submitted requests, and reconcile the resulting total with the service's usage record.

Sources: Flare text-to-image endpoint and token rates · Sunburst text-to-image endpoint and token rates · GPT Image 2.5 family overview and canonical cost examples

Separate image generation from the neighboring editing routes

The API documentation includes additional editing request types below the main text-to-image input section. A reader scanning the whole page may see reference-image or mask fields and mistakenly assume they belong to the endpoint being called. Read the input section for the exact route. The family overview lists separate generation and editing endpoints for each variant, which is a useful boundary when defining a comparison.

Sources: Flare text-to-image input schema · Sunburst text-to-image input schema · GPT Image 2.5 family overview and canonical cost examples

For example, a redesign based on an existing package photograph is a different task from inventing a package image from text alone. The former needs preservation evidence tied to an input image; the latter needs compliance with the written brief. Keep those cases in separate result sets. If you later compare editing variants, record the input files and protected regions before evaluating changes. None of those editing outcomes can be inferred from the matching generation fields described in this article.

Sources: Flare text-to-image input schema · Sunburst text-to-image input schema · GPT Image 2.5 family overview and canonical cost examples

Build an evidence record that supports the actual decision

A practical evaluation can retain a small set of representative briefs, repeated attempts and explicit rejection reasons. Keep the same text, canvas, named quality, background, output format and image count for each paired case. Review the required content before the visual polish. If an image looks persuasive but omits a requested item, record that omission rather than allowing general appearance to override the brief.

Sources: GPT Image 2.5 family overview and canonical cost examples

DualView's image comparison can help inspect corresponding regions, including small lettering and transparent edges. The tool makes differences easier to see; it does not supply a factual verdict about their cause. Preserve original outputs and the review notes needed to reproduce your conclusion. If Sunburst's stated focus on detail matches your work, test that hypothesis on your own artifacts. If Flare's general-use positioning matches it, test that too. Until then, the defensible conclusion is that the documented controls align, while the outcome tradeoff remains unmeasured here.

Sources: GPT Image 2.5 family overview and canonical cost examples

Frequently asked questions