OpenAI's GPT-Image-2.6 adds SVG and GIF output but drops Batch API support

New models and new formats

On November 4, OpenAI released two image models for its API: GPT-Image-2.6 Flare and GPT-Image-2.6 Sunburst. According to a dev.io write-up of the release, the models bring SVG generation, animated GIF output and a new complexity setting to the Images API — but neither model supports the Batch endpoint, which on the 2.5 generation halved the price of image output tokens.

The same day brought a consumer update. OpenAI's announcement on X introduced ChatGPT Images 2.6 with GIFs and reference images and claimed 50% faster image generation. The Decoder, citing The Verge, reports that the GIF feature is rolling out to ChatGPT and Codex users on web, desktop and mobile, and that OpenAI says ChatGPT and the API together now generate well over four billion images per week.

The two API models are split by job. Flare is the fast option, with images delivered in roughly six seconds at its quickest, while Sunburst aims at higher quality and more consistent results across a series of edits. Those figures come from OpenAI; the dev.to author notes he has not benchmarked either model himself.

Same token price, fewer lanes

Per-token pricing is unchanged. Both 2.6 models cost $5 per million text input tokens, $8 per million image input tokens and $30 per million image output tokens — identical to the 2.5 models and gpt-image-2. The differences are elsewhere.

On 2.5 Flare, routing work through Batch cuts output token cost to $15 per million. The 2.6 Flare model page lists Batch as unsupported, and neither new model offers it. There is also no dated snapshot yet: 2.5 users can pin gpt-image-2.5-flare-2026-09-08, while the 2.6 pages list only the alias itself.

Per-token parity may not mean per-image parity. In a forum thread cited in the dev.to post, one developer compared a single medium-quality image: 344 output tokens on 2.5 versus 1,136 on 2.6. Their arithmetic puts low-quality images at roughly 4.2x the cost and medium at 3.3x, with high unchanged. That is one person's sample rather than an OpenAI figure, but it suggests the new models may consume more tokens per image at some settings.

Complexity, SVG and GIF

Complexity is a new low, medium or high setting that controls how much planning the model does before rendering. It costs nothing extra and defaults to high when omitted. OpenAI's guide cautions that higher settings can add latency and introduce unwanted changes, so the dev.to author recommends setting it explicitly on every request, starting low for focused edits such as a background swap.

SVG output works through the generations endpoint with output_format: svg and n fixed at 1. Streaming, partial images, output compression and the prompt rewriter are not supported, and the edit endpoint cannot produce SVG. OpenAI describes the result as static vector data with no scripts, external resources or embedded rasters. Billing has two parts: the image model's rate for a reference image it renders first, plus a separate authoring model's rate for the tokens spent writing the SVG.

GIF output uses output_format: gif together with frame_count and frame_duration_ms. The documentation disagrees with itself here: the guide allows 2 to 64 frames while the API reference says 2 to 16, both defaulting to 9 frames at 200 ms. Until they agree, the dev.to author advises staying at 16 frames or fewer.

Markup-guided edits, another capability tied to the release, also work on supported 2.5 models according to the changelog.

What to check before switching

The documentation suggests a short migration checklist. Batch jobs should stay on 2.5 or gpt-image-2 for now, since neither 2.6 model lists the endpoint. There is no dated 2.6 snapshot to pin. Complexity and quality should be set explicitly rather than inherited. Running the same set of prompts through both generations and comparing output tokens per image — not just per-token price — is the safer way to evaluate a swap. The user field is deprecated for the Images API and should be replaced with safety_identifier. Finally, the API reference still describes the usage object as applying to gpt-image-1 only, so verify that 2.6 responses actually carry token counts before building cost tracking on them.

Why it matters

The 2.6 release adds capabilities that were previously impossible through the Images API: vector output and animated images from a text prompt. But dropping the Batch lane effectively doubles output cost for high-volume workloads, and the reported rise in tokens per image could push per-image costs up even at standard rates. Developers running nightly bulk jobs have little incentive to rush — 2.5 remains cheaper through Batch and can be pinned to a date — while 2.6's value is concentrated in the new formats. The gap between flat per-token pricing and rising token counts is exactly the kind of change that goes unnoticed without per-request usage logging.