GPT-Image-2.6 Official vs Reverse

TL;DR

If you need	Pick
Exact parity with OpenAI’s official fields, six `quality` tiers, any valid size, native 2K/4K	Official: `gpt-image-2.6-flare` (speed-first) / `gpt-image-2.6-sunburst` (editing-precision-first)
A hard cost ceiling: flat $0.025/image, the same price at 2K/4K, no dependence on size or quality	Reverse: `gpt-image-2.6-all`
Several images per call (1–4 images) or a 24-hour direct URL	`gpt-image-2.6-all`
Control over GIF frame count, frame duration, and per-frame size, or an SVG that pins the authoring model and itemizes text-model cost	The two official 2.6 models
Precise mask inpainting / multi-image fusion (up to 16 images) / WebP output / native 4K	The two official 2.6 models
Low-cost GIF and SVG without passing `svg.model` or paying authoring-model fees	`gpt-image-2.6-all`

This page compares only the three 2.6-generation models. For the full comparison of the 2.5 / 2 generation (gpt-image-2.5-flare / sunburst / gpt-image-2 and gpt-image-2-all / gpt-image-2.5-all / the three -vip models), see GPT-image-2.5 / 2 Official vs Reverse. gpt-image-2.6-all is a new reverse line for 2.6 — not a rename of gpt-image-2.5-all; the two differ in behavior and in parameter limits.

Full Comparison Table

Dimension	Official: `gpt-image-2.6-flare` / `gpt-image-2.6-sunburst`	Reverse: `gpt-image-2.6-all`
Channel nature	Direct connection to the OpenAI Images API; fields, error codes, and behavior match OpenAI official	Reverse-engineered ChatGPT web Images 2.6
Billing	Billed by actual token usage: text input $5 / image input $8 / image output $30 per 1M tokens	Per request: $0.025/image, the same at 2K/4K; `n` images are billed per image
Cost per image	Varies with `quality`, `size`, and reference-image count; roughly $0.006–$0.21 at 1K (reference values; your `usage` is authoritative)	Flat $0.025/image (`n=4` is $0.10)
Recommended endpoints	`/v1/images/generations` + `/v1/images/edits`	`/v1/images/generations` + `/v1/images/edits`
Images per call, `n`	1 image (issue parallel requests on the client for more)	1–4 (`n=5` and above returns 400)
`size` (native tier)	Any valid size: both edges a multiple of 16, aspect ratio ≤3:1, total pixels 655,360–8,294,400, longest edge 3840; plus 8 presets	Long edge 512–1536 as any integer (no 16-multiple requirement), aspect ratio ≤3:1, exact output
`size` (2K / 4K)	Native pixels (2048×2048, 2048×1152, 3840×2160, etc.); above 2560×1440 OpenAI marks these experimental	Super-resolution: common 2K/4K sizes are delivered exactly; a mismatch returns 502; square cap 2880; 4:1 is rejected with 400
`quality`	`auto` / `low` / `medium` / `high` / `xhigh` / `max`, six tiers	`auto` / `medium` / `high` only; `low` / `hd` return 400; the three tiers show no verifiable image-quality difference today
`complexity` (new in 2.6)	Official levels `low` / `medium` / `high`; same-prompt A/B evidence is still missing on the live route, so do not rely on it in production	Not supported on this route
Output formats	`png` / `jpeg` / `webp` / `gif` / `svg`	`png` / `jpeg` / `gif` / `svg`; WebP returns 400
Transparent background	`background=transparent` + `png` / `webp`; incompatible with `jpeg` (400); GIF is 1-bit transparency; SVG writes no background	`png` only: stable up to 2K, unstable at 4K
GIF control	Frame count, frame duration, and per-frame size are all controllable, subject to a sprite-sheet pixel budget (1024² / 2048² single frames do not work)	Frame count / duration exact; final dimensions are decided upstream; `output_format=gif` must be passed explicitly
SVG	`svg.model` must name the authoring model, and the text-model charge is billed separately; generations endpoint only, `n=1`	No `svg.model` needed (ignored if passed); no text-model fee; `viewBox` follows `size`
Mask inpainting	Official semantics (PNG with an alpha channel; still soft guidance)	Accepted, but no guarantee that only the masked region changes
Multi-image references	Up to 16 (`image[]`)	2 references work in testing; for more, compose them on the client or edit in steps
Response format	Fixed `b64_json` (raw base64, no prefix); does not accept `response_format` — passing it returns 400	`b64_json` by default; supports `response_format: "url"` (24-hour signed link; url responses may omit `size`)
Speed	OpenAI says 2.6 is 50% faster overall and that `flare` can be as fast as 6 s at `low` (OpenAI’s best case); high quality and 2K/4K are noticeably slower	Typically 10–46 s (1K 10–22 s, 2K 12–24 s, 4K 15–42 s); tail latency measured up to 198 s
Recommended client timeout	`low` ≥120 s / `medium` ≥240 s / `high` ≥600 s / `xhigh` ≥300 s / `max` ≥600 s	≥600 s
Token and group	Requires a Pay-as-you-go Priority Token; `Default` group, with the `image2Enterprise` enterprise group (1.2x) as a peak-hour fallback	A per-request model, so the `Default` group is enough; URL output needs no extra group
Stability	Official channel, error codes identical to OpenAI; occasional 429 in the `Default` group at peak	Reverse upstream; occasional 502 at 2K/4K, retry required; a size mismatch fails loudly instead of silently changing dimensions
Best for	Quality-sensitive production that needs official fields and native pixels and can absorb metered cost fluctuation	Capped cost, batch generation, 2K/4K large-canvas compatibility, and GIF / SVG / multi-image / URL work

The cost ranges in the table come from 2.5-generation same-price-tier measurements (2026-09-09, UTC+8) and from extrapolating 2K/4K by pixel count; 2.6 official models have no public per-tier measurements yet, so the actual cost per response (usage.output_tokens) is authoritative. The 2.6-all per-image price follows the Model Pricing tab and your final bill.

Billing Models and Cost

On APIYI, the most fundamental difference between the two routes is how usage is metered: the official models bill tokens as consumed, while 2.6-all caps cost per image. That decides which route is cheaper for a given workload.

Per-image cost at 1024×1024

`quality`	Official 2.6 (token-metered)	`gpt-image-2.6-all`
`low`	≈$0.006 (196 tokens at the 2.5 same-price tier); a single 2.6 measurement showed 824 tokens ≈ $0.025	$0.025
`medium`	≈$0.013 (439 tokens)	$0.025
`high`	≈$0.053 (1,756 tokens)	$0.025
`xhigh`	≈$0.094 (3,122 tokens)	$0.025
`max`	≈$0.211 (7,024 tokens)	$0.025

Model prices are aligned with the official price list and may change when OpenAI adjusts them; the table above is for reference only — the Model Pricing tab in the top navigation is authoritative: Model Pricing.

2K / 4K, multiple images, editing, and SVG

Scenario	Official 2.6 (token-metered)	`gpt-image-2.6-all`
2048×2048 `medium` / `high`	≈$0.21 / ≈$0.84 (pixel extrapolation, not an official price)	$0.025
2048×1152 `medium` / `high`	≈$0.06 / ≈$0.25 (pixel extrapolation)	$0.025
3840×2160 (4K) `medium` / `high`	≈$0.22 / ≈$0.87 (pixel extrapolation)	$0.025
4 images from the same prompt	4 calls, tokens add up	4 × $0.025 = $0.10
Edit with one 1024² reference image	Output tokens + input charge (a 1024² reference image is ≈$0.0082)	$0.025/image
SVG	Image segment + authoring-model text charge: `gpt-6-luna` ≈$0.026, `gpt-5.6-terra` ≈$0.039	$0.025
GIF, 512², 2 frames	≈$0.017	$0.025

There is no fixed official price table for 2K/4K. OpenAI publishes only the 1K per-image reference price, so the 2K/4K figures above extrapolate from 1K by pixel ratio and may be off by a wide margin; high above 2560×1440 is still an experimental tier. Use each call’s usage.output_tokens as the real cost. For 2.6-all, $0.025/image with the same price at 2K/4K is the documented position, and your final bill is authoritative; current prices live in the Model Pricing tab: Model Pricing.

How to decide quickly: on pure output tokens, $0.025 of official billing equals about 833 output tokens, which sits between the 2.5-generation medium and high tiers. So:

1K at low or medium quality: the two routes land in the same order of magnitude, and the official route may be cheaper based on actual usage; that said, the single 2.6 measurement (low, 824 tokens ≈ $0.025) suggests the advantage may already be marginal on 2.6, so do not carry the 2.5 numbers over as a conclusion.
1K at high and above, or 2K/4K at medium or high quality: 2.6-all’s flat $0.025 wins outright — high-quality 2K/4K can differ by an order of magnitude.
Edits with reference images: each 1024² reference image on the official route adds about $0.0082 of input cost and pushes the single-call cost up quickly; 2.6-all bills per image and does not stack reference-image charges.

Before going to production, run one round of your own prompts on each route and record both usage and latency: convert output tokens to cost on the official route, and multiply image count by unit price on 2.6-all. Any price-performance conclusion only holds for the prompts you actually tested.

Key Differences in Detail

1. `size`: any valid size + native 2K/4K vs. 1536 native + super-resolved 2K/4K

Official 2.6 follows the official size rules; all four conditions must hold at once:

Longest edge ≤ 3840
Both edges are multiples of 16
Aspect ratio ≤ 3:1
Total pixels between 655,360 and 8,294,400

There are 8 preset sizes: auto, 1024x1024, 1536x1024, 1024x1536, 2048x2048, 2048x1152, 3840x2160, 2160x3840. 2K/4K are native pixels, not upscaled. 2.6-all splits into two tiers:

Native tier: long edge 512–1536, and any integer is delivered exactly with no 16-multiple requirement (1000x1000, 1280x720, and 1536x864 all pass), aspect ratio ≤3:1
Super-resolution tier: common sizes such as 2048x2048, 2048x1152, 2048x1536, 1920x1080, 3840x2160, and 2880x2880 are delivered exactly; a mismatch returns 502 size_not_deliverable instead of silently snapping to a different size. The square cap is 2880 (4096x4096 returns 502), and ratios beyond 3:1 such as 4096x1024 return 400

One easily missed difference: raster generation on the official route has a minimum pixel budget (about 655,360), so small images like 512x512 are rejected; 2.6-all can produce 512x512 and 512x384. For small icons or thumbnails, 2.6-all is the more flexible choice.

2. `n`, `quality`, and `complexity`: official tiers vs. three tiers plus multiple images

n: the official route always returns one image, so multiple images require client-side concurrency; 2.6-all supports 1–4 images, bills per image, and returns 400 from n=5.
quality: the official route exposes all six tiers (low / medium / high / xhigh / max / auto), which is the officially committed quality control; 2.6-all accepts only auto / medium / high (low / hd return 400), and the three tiers currently show no verifiable image-quality difference — do not use it to control quality, and do not expect it to control size.
complexity: a parameter introduced in 2.6. The official-route docs define three official levels (low / medium / high, defaulting to high when omitted), but no same-prompt A/B test on the live route has demonstrated the effect yet, so do not rely on it in production; 2.6-all does not support this parameter.

3. GIF and SVG: control vs. cost

GIF

Dimension	Official 2.6	`gpt-image-2.6-all`
Frame count	2–16, default 9	No documented range; 4 / 6 / 8 frames all came out exact in testing
Frame duration	20–2000 ms, default 200 ms, rounded to 10 ms	120 / 150 / 300 ms all came out exact in testing
Per-frame size	Must be a multiple of 16; constrained by the sprite-sheet pixel budget	`size` has no effect; final dimensions are decided upstream
Final dimensions	Predictable: 512×512 works at every frame count; 1024² / 2048² single frames do not work	Not guaranteed: 384×512, 507×506, and 619×623 have all appeared in testing
Edit endpoint	Supported	Docs only demonstrate the generations endpoint; verify edit + GIF yourself

The official 2.6 route draws GIFs into a single sprite sheet and then cuts it into frames, so the limits apply to the sheet: longest edge ≤3840, total pixels ≤8,294,400, aspect ratio ≤3:1. The square per-frame cap shrinks as the frame count grows: 960×960 for 2–9 frames, 816×816 for 10–12 frames, and 720×720 for 13–16 frames. Exceeding the budget returns 400; a frame_count of 1 or 17 does not error but falls back to the default 9 frames / 1.8 seconds, so verify the real frame count with ffprobe. SVG

Dimension	Official 2.6	`gpt-image-2.6-all`
Required fields	`output_format="svg"` + `svg.model` (the authoring model)	Just `output_format="svg"`
Extra cost	The authoring model bills at the selected text model’s input / output rates (about $0.001–$0.013 per image)	None; $0.025 per image
Endpoint / image count	Generations only, `n=1`; the edit endpoint does not support SVG	Generations; `viewBox` follows `size`
Size	`viewBox` follows `size`; no public measurements for large sizes yet	`viewBox` tested up to 8192; 4:1 ratios are not bound by the raster 3:1 limit

The official 2.6 route requires you to name the authoring model (svg.model) yourself — omit it and the request returns 400 SVG generation requires 'svg.model' — and the cost has two parts: the image segment plus the text segment. 2.6-all does not need svg.model and ignores it if passed. Pick the official route when you need to itemize SVG text cost; pick 2.6-all when you want cheap and few field dependencies.

4. Response format: `b64_json` vs. `b64_json` + URL

Official 2.6: always returns b64_json (raw base64, no data: prefix) and does not accept response_format — passing it returns 400. To get a URL you must persist the image to your own storage.
2.6-all: b64_json by default, or pass response_format: "url" explicitly for a 24-hour signed link. Note that url responses may omit the size field; only b64 responses carry it. Regenerate after the URL expires, and re-host promptly on your side.

Neither route’s b64_json carries a data: prefix, so the decode logic can be shared.

5. Editing: mask, multiple images, and markup

Capability	Official 2.6	`gpt-image-2.6-all`
Mask inpainting	Official semantics: PNG, alpha channel, under 4MB, but still soft guidance with no pixel-exact boundary guarantee	Accepted, but no guarantee that only the masked region changes; for complex edits, state in the prompt exactly what to change and what to keep
Multi-image references	Up to 16 (`image[]`); refer to them as “image 1” / “image 2” in the prompt	2 references work in testing; for more, compose first or edit in steps
Edit with `auto` size	Determined by existing input semantics	Output is normalized to about 1.57 MP while preserving the input aspect ratio; the original pixel dimensions are not guaranteed
Markup-guided editing	New in 2.6, but passthrough differs by route — test it in your own group	Not documented on this route

6. Speed, timeouts, and stability

Keep official statements and measurements apart:

Official 2.6: OpenAI says generation is 50% faster overall and that flare reaches 6 seconds at low. That is OpenAI’s best case, not a guarantee for every request. The site has no per-tier 2.6 measurements yet; use the 2.5 same-price-tier numbers as a reference: 2.5-flare at 1024² measured 10 s at low / 21 s at high / 45 s at max, and 2.5-sunburst 14 / 42 / 142 s. High quality and 2K/4K are noticeably slower.
2.6-all: typically 10–46 s (1K 10–22 s, 2K 12–24 s, 4K 15–42 s), but tail latency has measured up to 198 s, so configure clients uniformly at 600 s.

Both routes are synchronous: there is no task ID, so if the client disconnects the result is lost while the request is still billed. Relax timeouts, reverse proxies, and serverless execution limits together. Concurrency and stability:

The official route runs through OpenAI, defaults to about 100 RPM, and adjusts dynamically with overall platform concurrency; the Default group occasionally returns 429 at peak, and switching to the image2Enterprise enterprise group (1.2x) can bridge the gap.
2.6-all passed 12×2, 16×1, and 8-way concurrency at 1K in testing with no 429s; 2K/4K has not been load-tested, so start with 4–8 concurrent requests and watch tail latency. 2K/4K occasionally returns 502 size_not_deliverable; retry or switch to a supported size.
On both routes, retry 5xx and timeouts twice with exponential backoff, and back off on 429.

When to Pick Each

Pick the official gpt-image-2.6-flare / sunburst

Fields and behavior must match OpenAI exactly: existing projects built on the official SDK or official fields migrate with zero changes
You need all six quality tiers, especially the finished-asset quality of xhigh / max
You need native 2K/4K pixels for print, fine texture, or hard detail requirements
You need precise masks, multi-image fusion (16 images), or WebP output
You need controllable GIF per-frame sizes, or an SVG with a named authoring model and itemized cost
You can accept metered cost fluctuation in exchange for the official route’s stability

Pick gpt-image-2.6-all (reverse)

Cost must be capped: flat $0.025/image, the same at 2K/4K, easy to budget
Batch production, infographics, marketing collateral, e-commerce assets
2K/4K large-canvas compatibility: you want a bigger canvas without native-pixel detail
Low-cost GIF / SVG: no svg.model and no text-model fee
Several images per call (1–4) or a 24-hour direct URL
Fast iteration and the native ChatGPT look up to 1536 (with fingerprint)

Client Settings

Setting	Official 2.6	`gpt-image-2.6-all`
Client timeout	`low` ≥120 s, `medium` ≥240 s, `high` ≥600 s, `xhigh` ≥300 s, `max` ≥600 s	≥600 s
Retry strategy	Exponential backoff twice on 5xx and timeouts; back off on 429	Same, except switch size first on 502 `size_not_deliverable`
Concurrency	About 100 RPM by default; switch to `image2Enterprise` at peak	Start at 10–16 concurrent requests for 1K; 4–8 for 2K/4K
Response handling	Always b64, decode it yourself; do not send `response_format`	b64 or url; re-host url responses promptly, and they may omit `size`
Size validation	Validate against the four official constraints	Use the response `size` and the actual image dimensions; an explicit size mismatch returns 502
Cost accounting	Record `usage.output_tokens` and convert at $30 per 1M	Record returned image count × $0.025
Token type	Must be Pay-as-you-go Priority	A per-request model; the `Default` group is enough

import base64
import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["APIYI_API_KEY"],
    base_url="https://api.apiyi.com/v1",
    timeout=600,
)

# Official 2.6: six quality tiers + native sizes
official = client.images.generate(
    model="gpt-image-2.6-flare",
    prompt="Minimalist specialty coffee poster, product and soft morning light in focus, with space reserved for a headline",
    size="2048x1152",
    quality="high",
)

# 2.6-all: flat per-image price; pass response_format explicitly when you need a direct URL
reverse = client.images.generate(
    model="gpt-image-2.6-all",
    prompt="Minimalist specialty coffee poster, product and soft morning light in focus, with space reserved for a headline",
    size="2048x1152",
    quality="medium",
    response_format="b64_json",
)

with open("coffee-official.png", "wb") as f:
    f.write(base64.b64decode(official.data[0].b64_json))

with open("coffee-reverse.png", "wb") as f:
    f.write(base64.b64decode(reverse.data[0].b64_json))

FAQ

Can I switch between the two channels by changing only the model name?

Basic text-to-image and editing can share one codebase, but the parameter semantics are not fully equivalent, so normalize once when you switch:

size: the official route requires 16-multiples and a total-pixel range; 2.6-all’s native tier accepts any integer, and 2K/4K is super-resolution
quality: six tiers on the official route; 2.6-all only accepts auto / medium / high
response_format: passing it returns 400 on the official route; 2.6-all accepts url
n: the official route returns 1 image; 2.6-all returns 1–4
GIF / SVG: different field requirements and limits

Neither route’s b64_json carries a data: prefix, so the decode logic can be reused.

Why is 2.6-all so much cheaper? Does image quality suffer?

Three reasons: per-image pricing covers 1K–4K (the official route meters tokens, and token volume climbs steeply at high quality and large sizes); 2K/4K is super-resolution, not native pixels; and there are fewer quality tiers. The two routes are positioned differently on quality: 2.6-all keeps the native ChatGPT web quality and fingerprint up to 1536, while the official route uses the official API’s native quality tiers. There is no public blind test on identical prompts, so we do not declare a winner — run your own assets through both and compare.

When do I have to use the official route?

Pick the official gpt-image-2.6-flare / sunburst when you need any of: exact parity with OpenAI’s official fields, all six quality tiers (including xhigh / max), native 2K/4K pixels, precise masks, multi-image fusion (up to 16 images), WebP output, controllable GIF per-frame size, or an SVG with a named authoring model and itemized text-model cost.

When should I prefer 2.6-all?

Capped cost, batch generation, 2K/4K large-canvas compatibility, low-cost GIF / SVG, 1–4 images per call, a 24-hour direct URL, or simply fast draft iteration — 2.6-all’s $0.025/image is the better deal in all of these. Remember that its 2K/4K is super-resolution: a bigger image does not mean more detail.

2K/4K: native pixels or super-resolution?

Native detail, print-grade delivery, a hard 4K requirement: pick the official route for native pixels, accepting that token billing is noticeably more expensive. You just need a bigger canvas (posters, large screens, long e-commerce images) at a capped cost: pick 2.6-all’s super-resolution tier — common 2K/4K sizes are delivered exactly; for quality, stay in the native tier at or below 1536.

Does a 2K/4K request on 2.6-all always succeed?

Not always. Common sizes (2048x2048, 2048x1152, 2048x1536, 3840x2160, 2880x2880, and others) are delivered exactly; squares above 2880, 4:1 ratios, and some 4K transparent-background requests fail (502 size_not_deliverable or 400). Validate against the response size and the actual image dimensions, and switch size or retry on failure.

Can I set the final GIF dimensions?

The official route can control per-frame size (a multiple of 16, constrained by the sprite-sheet budget); 2.6-all cannot — size has no effect on GIF, only frame count and duration are guaranteed, and the final pixels are decided upstream. To fix GIF dimensions today, resize or crop the file on the client.

How do I choose between the two routes for SVG?

To name the authoring model, match OpenAI’s official fields, and accept a separately billed text model: pick the official route (you must pass svg.model, otherwise 400). For cheap, fewer field dependencies, and a large viewBox: pick 2.6-all (no svg.model needed, $0.025 per image).

Can I use the complexity parameter?

complexity is a planning-control parameter added upstream for 2.6. The official-route docs define three official levels, but no same-prompt A/B test on the live route has demonstrated the effect yet, so do not rely on it in production; 2.6-all does not support it. You can send it for experiments, but do not treat it as a stable quality or cost control.

Can I run both channels at once for failover?

Yes — and we recommend it. A common pattern is to run one route as primary by cost or capacity and the other as fallback: switch to 2.6-all when the official Default group returns 429 at peak, or switch to the official route when 2.6-all fails on content policy or size. Both routes use /v1/images/generations and /v1/images/edits, so normalize the response fields and parameters once in your business layer.

GPT-Image-2.6 / 2.5 / 2 Official Relay Overview - Full integration docs for the five official models
GPT Image 2.6 New Capabilities - complexity, SVG, GIF, markup-guided edits, and the Playground
GPT-Image-2.6-All Overview - Full parameters, sizes, and error codes for the 2.6 reverse route
GPT-image-2.5 / 2 Official vs Reverse - The previous-generation comparison
Output format and background incompatibilities - The official 2.6 transparent × png / jpeg / webp / gif / svg matrix
How to choose an SVG reasoning effort - Authoring models and svg.reasoning.effort for official SVG
Image API Essentials & Best Practices - Timeouts, disconnects, and retries
Model Pricing - Live prices for the two official models and 2.6-all

Basics

Basic API

Image API (Official)

Video API (Official)

Multimodal Understanding API

Text Generation

Audio API (Official)

Retrieval & Safety

GPT-Image-2.6 Official vs Reverse

TL;DR

Full Comparison Table

Billing Models and Cost

Per-image cost at 1024×1024

2K / 4K, multiple images, editing, and SVG

Key Differences in Detail

1. `size`: any valid size + native 2K/4K vs. 1536 native + super-resolved 2K/4K

2. `n`, `quality`, and `complexity`: official tiers vs. three tiers plus multiple images

3. GIF and SVG: control vs. cost

4. Response format: `b64_json` vs. `b64_json` + URL

5. Editing: mask, multiple images, and markup

6. Speed, timeouts, and stability

When to Pick Each

Pick the official gpt-image-2.6-flare / sunburst

Pick gpt-image-2.6-all (reverse)

Client Settings

FAQ

​TL;DR

​Full Comparison Table

​Billing Models and Cost

​Per-image cost at 1024×1024

​2K / 4K, multiple images, editing, and SVG

​Key Differences in Detail

​1. size: any valid size + native 2K/4K vs. 1536 native + super-resolved 2K/4K

​2. n, quality, and complexity: official tiers vs. three tiers plus multiple images

​3. GIF and SVG: control vs. cost

​4. Response format: b64_json vs. b64_json + URL

​5. Editing: mask, multiple images, and markup

​6. Speed, timeouts, and stability

​When to Pick Each

Pick the official gpt-image-2.6-flare / sunburst

Pick gpt-image-2.6-all (reverse)

​Client Settings

​FAQ

​Related Docs

TL;DR

Full Comparison Table

Billing Models and Cost

Per-image cost at 1024×1024

2K / 4K, multiple images, editing, and SVG

Key Differences in Detail

1. `size`: any valid size + native 2K/4K vs. 1536 native + super-resolved 2K/4K

2. `n`, `quality`, and `complexity`: official tiers vs. three tiers plus multiple images

3. GIF and SVG: control vs. cost

4. Response format: `b64_json` vs. `b64_json` + URL

5. Editing: mask, multiple images, and markup

6. Speed, timeouts, and stability

When to Pick Each

Client Settings

FAQ

Related Docs