GPT Image 2.5 to 2.6: a static-image migration checklist

A model upgrade is useful only if it still delivers the asset your application needs. This guide compares the repository contracts for gpt-image-2.5-flare and gpt-image-2.6-flare, with the corresponding Sunburst variants as separate candidates. It does not claim that 2.6 is faster, cheaper or visually better. Keep a working 2.5 integration until your own acceptance checks justify a change.

Separate a model upgrade from a format experiment

The 2.6 schema extends the 2.5 schema. Both accept a prompt and optional reference images, sizing controls, quality and background. The shared quality choices are low, medium, high, xhigh, max and auto. The same label is not evidence of equal effort, price or output across versions.

Decision	Static-image migration	Separate experiment
Model	Change only the exact model ID	Compare Flare and Sunburst separately
Format	Keep PNG, JPEG or WebP unchanged	GIF and SVG are additional 2.6 formats
Size	Keep one sizing strategy	Test a new aspect ratio later
References	Reuse identical authorized source files	Test new reference sets later
Acceptance	Reuse the existing delivery rubric	Define animation/vector checks before trying new formats

The repository adds frame_count and frame_duration_ms for GIF requests, prohibits output_compression with GIF/SVG, and disallows reference images for SVG in this contract. Schema presence does not establish that an account’s current provider route supports every combination. A static migration does not need these fields. Do not transfer a native vendor request unchanged into the platform task envelope.

Freeze one baseline request

The following body is for POST /v1/tasks. It is a request example, not a generated sample or benchmark. Check the live /v1/media-models contract and account access before any billable call.

{
  "model": "gpt-image-2.6-flare",
  "input": {
    "prompt": "A single blue ceramic desk lamp on an opaque warm-white studio background. Entire lamp visible with empty space around its silhouette. No words, logos or extra objects.",
    "resolution": "1k",
    "aspect_ratio": "1:1",
    "quality": "medium",
    "background": "opaque",
    "output_format": "png"
  }
}

For a 2.5 baseline, change only model to gpt-image-2.5-flare. Do not add size to this request: when used, it takes precedence over aspect ratio and introduces a different sizing path. Record actual returned dimensions; a 1k label alone is not an acceptance test. For an existing reference edit, preserve the reference URLs and their file hashes, using the Flare edit reference.

Save each returned task ID immediately and poll that task. An ambiguous submission timeout is not permission to automatically submit the same paid job again. Keep the original output files and usage records with the request manifest.

Use a delivery-based comparison sheet

Choose a small set of representative briefs before generating anything: one simple isolated object, one authorized reference edit, one composition with required empty space, and one typography-heavy asset if that is part of your actual workload. This is a proposed test set, not evidence of measured model performance.

Record one row per attempt: brief ID, source version, model, prompt version, requested controls, task ID, actual dimensions, file type, review result, elapsed time and final charge. Count failures and rejected images as attempts. Compare accepted outputs at the same display size, with the model name hidden from reviewers where practical.

Gate	Inspect	What a failure means
Integration	Task completion and retrievable asset	Keep separate from visual quality
File contract	Decodable file, actual format/dimensions, alpha if required	Downstream export may break
Composition	Complete subject and required empty space	Prompt or generation is not delivery-ready
Identity	Reference shape, markings and colors	More editing or a different workflow is needed
Typography	Every required character at delivery size	Use approved typesetting if exact text is mandatory

A smaller accepted set can make a lower per-request price more expensive per usable asset. Compute total observed charges divided by accepted deliverables; if there are none, report “no accepted deliverables,” not zero cost. Do not extrapolate a handful of assets into a universal ranking.

Decide and retain a usable fallback

Approve the migration only for the task classes that pass. Keep the prior model ID, prompt and asset fixtures in version control. If a downstream decoder fails, investigate format handling before changing the prompt. If identity or text regresses, keep that workload on the previous configuration while reviewing examples. An application fallback should be explicit and budgeted; it must not silently launch a second paid task after an uncertain first submission.

Continue with transparent asset inspection, poster text acceptance, batch budgeting, and the 2.5 Flare, 2.6 Flare, 2.6 Sunburst references.

Evidence and limits

Checked 2026-11-07 against repository revision df986532: packages/server/src/providers/gpt-image25.ts, gpt-image26.ts and the inherited gpt-image2.ts schema. OpenAI’s 2.6 Flare page confirms model identity and image generation/editing positioning. Platform fields above are source-verified; production account availability and output quality were not tested. This article does not replace live schema or account pricing.