GPT-Image-2.6 Outputs SVG and GIFs. Unlike 2.5, You Can't Run It Through Batch

• Book: LLM Observability Pocket Guide
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

---

If you run image generation through OpenAI's Batch API, the new models aren't for your nightly job yet. On November 4, OpenAI released GPT-Image-2.6 Sunburst and GPT-Image-2.6 Flare, adding SVG generation, animated GIF generation and a new complexity setting. The Flare model page lists two supported endpoints: image generation and image edit. Batch is marked unsupported. The 2.5 Flare page still lists Batch, where image output costs $15 per million tokens instead of $30.

That is the trade on day one: new output formats at the same per-token price, minus the half-price lane and a pinned snapshot.

What shipped on November 4

OpenAI's announcement on X led with the consumer side: ChatGPT Images 2.6, now with GIFs and reference images, plus two new API models with "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."

For the API, OpenAI's release announcement splits the two models by job. Flare is the fast one, producing images "in as little as six seconds." Sunburst targets higher quality and "greater consistency across edits." I haven't run either model, so treat those as OpenAI's numbers.

The image generation guide says both models "support complexity control, markup-guided edits, SVG output, and animated GIF output through the Image API." The changelog says markup-guided edits also work on supported 2.5 models.

One press, two new output trays. The batch conveyor behind it isn't connected yet.

Same price per token, fewer lanes

The pricing page puts both 2.6 models at exactly the rates of gpt-image-2.5-flare, gpt-image-2.5-sunburst and gpt-image-2: $5 per million text input tokens, $8 per million image input tokens and $30 per million image output tokens. The differences are elsewhere:

	gpt-image-2.5-flare	gpt-image-2.6-flare
Image output, standard	$30 / 1M tokens	$30 / 1M tokens
Batch endpoint	Yes, $15 / 1M output	Not supported
Dated snapshot	gpt-image-2.5-flare-2026-09-08	None listed
SVG and GIF output	Not listed	Yes

The snapshot row matters if you pin versions. The 2.6 Flare page and the 2.6 Sunburst page each list a single snapshot, the alias itself. On 2.5 you can pin gpt-image-2.5-flare-2026-09-08. On 2.6 you can't pin a dated version yet.

Per-token parity also doesn't mean per-image parity. In the forum thread, one developer posted a single comparison: 344 output tokens for a medium image on 2.5, and 1,136 on 2.6. Their own estimate puts low at 4.2x and medium at 3.3x the 2.5 cost, with high unchanged. That is one person's sample and arithmetic, not an OpenAI figure. It is still a reason to measure before you swap a model ID in production.

The new knobs: complexity, SVG, GIF

Per the guide, complexity (low, medium or high) sets "how much the image model plans before rendering," costs nothing extra, and defaults to high when you omit it. Higher settings can add latency and "introduce unwanted changes," so for a focused edit like swapping a background or a sign, start lower. Set it explicitly instead of inheriting high.

SVG output goes through POST /v1/images/generations with output_format: "svg" and n set to 1. Streaming, partial images, output_compression and prompt_rewriter aren't supported, and the edit endpoint can't produce SVG. The guide says the result is static vector content with no scripts, external resources or embedded raster images. Billing has two parts: the image model's rate for a reference image it renders first, plus "the authoring model's rate" for the tokens spent writing the SVG.

GIF output uses output_format: "gif" with frame_count and frame_duration_ms. Mind the docs here. The guide allows 2 to 64 frames. The API reference says 2 to 16. Both default to 9 frames at 200 ms. Until they agree, stay at 16 or fewer.

If you leave complexity unset, both 2.6 models plan at high.

Measure before you switch

Here is a GIF request that sets every new knob explicitly and keeps the raw response, so you can read the token counts before you decode the image:

curl -s https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2.6-flare",
    "prompt": "A paper plane looping once, flat style",
    "output_format": "gif",
    "frame_count": 9,
    "frame_duration_ms": 200,
    "quality": "high",
    "complexity": "low"
  }' > plane.json

jq '.usage' plane.json
jq -r '.data[0].b64_json' plane.json \
  | base64 --decode > plane.gif

The API reference describes a usage object with input_tokens and output_tokens, and shows it in its example response. Its description still says it applies to gpt-image-1 only, so check that your 2.6 responses carry it before you build cost tracking on it.

A swap checklist, from what the docs say today:

1. Batch jobs stay on 2.5 or gpt-image-2 for now. Neither 2.6 model lists the Batch endpoint.
2. If you pin versions, note that 2.6 has no dated snapshot yet.
3. Set complexity and quality on every request. Don't inherit high or auto.
4. Run the same 20 or so prompts through 2.5 and 2.6 at your usual quality and compare output tokens per image, not just per-token price.
5. If you send the user field, switch it. The guide says it is deprecated for the Images API; send the same identifier as safety_identifier.

Who should move now

If you need vector icons or short loops from an API, the November 4 changelog ties SVG and GIF generation to the 2.6 release, and that alone may justify it. If you generate thousands of raster images overnight, 2.5 through Batch is still half the output price, and you can pin it to a date.

The guide's own examples still use GPT Image 2.5. Log output tokens per image on 2.6 for a week before you move anything off the nightly Batch job.

---

If this was useful

The price per token didn't change, and the bill per image still might. That gap is what the LLM Observability Pocket Guide is about: logging token usage per request, tracking cost per feature, and catching a model swap that quietly raises your spend. If you run coding agents next to these APIs, I also build Hermes IDE, a free desktop app that runs Claude Code, Codex and others side by side, where each task can get its own branch and worktree (GitHub).