The GPT Image 2.5 API: Flare and Sunburst
Two model IDs, six quality settings, and one decision to make per job. Here is how the API surface is laid out and which tier fits which workload.
This is the first release in the family to split its API lineup by workload. GPT Image 2 was one model with a quality dial; GPT Image 2.5 is two models, each with a six-position quality dial. The naming does not follow the usual mini/standard/pro convention, which trips people up, so it is worth stating what the codenames mean: Flare is the fast default, Sunburst is the precise one. Neither is a cut-down version of the other, and both are full GPT Image 2.5 models.
Both accept text and image input and return image output. Neither handles audio or video, and neither supports function calling — if image generation is a step inside an agent, you drive it from a text model through the Responses API image generation tool rather than expecting the image model to orchestrate anything itself.
GPT-Image-2.5 Flare
gpt-image-2.5-flare Fast, high-quality everyday image generation
- Speed
- Very fast
- Performance
- Higher
- Input
- Text, image
- Output
- Image
- Image output
- $30 / 1M tokens
Built for
- ›Creator and social content
- ›In-product image generation
- ›Visual search and thumbnails
- ›Rapid image prototyping
- ›High-volume batch jobs
Delivers higher-quality images than GPT Image 2 at 50% lower latency. Manus reported 2-4x the speed of GPT Image 2 in its own evaluations.
GPT-Image-2.5 Sunburst
gpt-image-2.5-sunburst Most capable model for generation and editing
- Speed
- Medium
- Performance
- Highest
- Input
- Text, image
- Output
- Image
- Image output
- $30 / 1M tokens
Built for
- ›Production-ready campaign creative
- ›Polished product imagery
- ›Multi-turn retouching chains
- ›Brand-controlled art direction
- ›Anything going to print
Built for workflows where editing precision matters more than turnaround. Generation takes longer than Flare by design.
Quality settings
Both models accept six values. The previous generation exposed three named tiers plus auto, so xhigh and max are genuinely new headroom rather than a rename.
lowmediumhighxhighmaxauto Where to sit by default
Draft at low, ship at high.
On the previous generation those two tiers were roughly 35x apart in cost per image, and the
draft is discarded either way. auto is convenient but
unpredictable in a budget spreadsheet.
On xhigh and max
No per-image figures are published for either. Because billing is token-based, the only honest way to price them is to run a representative batch and read the output token count off your own usage. Do that before you commit to a tier in a client quote.
Endpoint support
| Endpoint | Path | Status | Notes |
|---|---|---|---|
| Image generation | /v1/images/generations | Supported | Text prompt in, image out. The primary path. |
| Image edit | /v1/images/edits | Supported | Image plus instruction in. Where scoped editing lives. |
| Responses | /v1/responses | Supported | Select the model as the image generation tool inside an agent flow. |
| Chat Completions | /v1/chat/completions | Supported | Supported, though the Image API is the more direct route. |
| Assistants | /v1/assistants | Supported | Available for assistant-shaped integrations. |
| Batch | /v1/batch | Supported | The route for large non-interactive jobs. |
| Realtime | /v1/realtime | No | Not supported. These models are not streaming-capable. |
| Embeddings | /v1/embeddings | No | Not supported. |
| Fine-tuning | /v1/fine-tuning | No | Not supported. There is no custom-training path. |
| Function calling | — | No | Not supported. Orchestrate from a text model instead. |
Request shapes
Generate with Flare
curl https://api.openai.com/v1/images/generations \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-image-2.5-flare",
"prompt": "A screen-printed concert poster, two ink colours on off-white stock. The headline reads \"NIGHT FERRY\" in a heavy geometric sans.",
"size": "1024x1536",
"quality": "medium"
}'Scoped edit with Sunburst
curl https://api.openai.com/v1/images/edits \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-F model="gpt-image-2.5-sunburst" \
-F image="@product.png" \
-F quality="high" \
-F prompt="Change only the label to matte black. Keep the bottle geometry, the lighting and the crop exactly as they are."Choosing between the two, honestly
OpenAI's own guidance is to start with Flare and reach for Sunburst when precision across edits matters. That is good advice, and it under-sells how lopsided the split is in practice. The vast majority of GPT Image 2.5 API traffic is single-shot generation at moderate quality, feeding a thumbnail, a social card or a placeholder. All of that belongs on Flare, where the latency advantage compounds across a queue and the quality is already above the previous flagship.
Sunburst earns its slot in a narrower band: work that goes through several rounds of art direction before it ships. Campaign creative, packaging, anything where a human will say "same again but the label is matte" four times. There, generation time is irrelevant next to whether turn four still looks like turn one, and that is the axis Sunburst is tuned on.
The trap is routing by prestige rather than by workload. Sunburst is not the paid tier and Flare is not the free one — the published token rates are identical. Sending everything to Sunburst buys you longer generation times and, on single-shot work, output you could not distinguish in a blind test.
Access, limits and operational notes
Access to GPT Image 2.5 sits at the account level rather than the model level. If your organisation already has GPT Image 2 enabled, both new models appear on the same key with no separate approval step. Rate limits follow your usage tier in the standard way, and because image generation consumes output tokens rather than requests-per-minute in any intuitive sense, the ceiling you hit first is usually the token bucket rather than the request one.
Two operational details are easy to miss. The first is that OpenAI states the GPT Image 2 token calculator does not estimate GPT Image 2.5 token consumption, so any capacity model you carried over from the previous generation is now guesswork. Instrument a representative batch and read the real numbers off your usage dashboard before you commit to a throughput target.
The second is failure handling. Image jobs fail for content-policy reasons more often than text completions do, and a queue that treats every non-200 as retryable will burn budget re-submitting prompts that will never succeed. Classify refusals separately from transient errors, and log the prompt alongside the response so a human can see what tripped it.