quality vs complexity: how visual fidelity and planning depth split in Images 2.6
Images 2.6 introduces (and systematically documents) two independent controls in the API: quality and complexity. Per the product announcement, image quality controls visual detail and fidelity, while complexity guides “how much planning goes into the scene.” OpenAI explicitly recommends: use low complexity for most edit tasks for faster edits, pairing with the quality tier the workflow needs. The Changelog (2026-11-04) also lists adjustable complexity among 2.6 launch highlights.
👉 Try the GPT Image 2.6 API on PoYo: per-image pricing and online playground.
Confusing the two treats “draw finer” and “think more” as one knob. Official definitions go the other way: the former governs render fidelity; the latter governs planning depth before render. If you keep the old habit that “omitting a parameter means maximum,” complexity silently lands on default high, which can slow edits and introduce unwanted changes.
Values, defaults, and cost
Per the image generation guide and image prompting guide:
| Parameter | Role | Allowed values | When omitted |
|---|---|---|---|
quality | Controls renderable visual detail (e.g., texture, small type) | auto, low, medium, high, xhigh, max | Docs say default auto (consistent with prior GPT Image habit) |
complexity | Controls how much planning before render | low, medium, high | Both Flare and Sunburst default to high |
Adjusting complexity has no separate billing line. Higher complexity may add latency and unwanted extra changes, so docs recommend comparing results on the specific task rather than always maxing out. The product page further notes: scenes with many elements or constraints can try medium or high complexity; fast edits suit lower settings. Lower complexity fits focused changes such as swapping a background or street sign; higher complexity helps dense text, complex layout, and inter-object relationships.
When Flare runs at quality=low, OpenAI says generation can finish in about six seconds; Sunburst at medium/high quality is positioned for more detail and stronger edit consistency. Those are combined effects of model tier and quality tier—they cannot be attributed to complexity alone, and you should not claim “one tier is always faster” without comparison.
How to A/B
The prompting guide gives clear tuning discipline: change one setting at a time. Freeze quality when comparing complexity; if layout is already correct but small text is hard to read, compare different quality values at the same complexity. Docs use the same soccer-paper-cut prompt with fixed size="1024x1536" and quality="medium" to show Sunburst differences across low/medium/high complexity in trophy, “CHAMPIONS” sign placement, and jersey detail: at low complexity a crown appears on the trophy and a large banner sits in front of the team; medium adds laurel and crest; high moves the sign to the stands and leaves the foreground to players and jersey folds. The example shows that when the prompt leaves layout, text, and style under-specified, raising complexity meaningfully changes composition decisions; when layout, copy, and style are already locked in the prompt, higher complexity may show almost no difference.
For targeted edits, official advice is to start at low and check that surrounding detail stays intact. Product announcement and generation-guide language agree: focused changes such as background swaps or street-sign edits suit lower complexity; dense text, complex layout, and object relationships are where medium/high are more worth trying. With markup edits, low complexity usually aligns with “only change the circled object” prompt constraints and helps suppress out-of-circle drift.
Practical combinations (still within documented inference)
Treat “fast draft” as: Flare + quality=low (or medium) + explicitly set complexity to low for edits (because omitting defaults to high and may actually be slower). Treat “final asset” as: after choosing Flare or Sunburst, raise quality, and A/B whether to raise complexity separately—do not assume max quality must pair with high complexity. When migrating existing 2.5 workflows, the prompting guide suggests keeping prompts, references, size, quality, and output format unchanged on the first comparison, leaving complexity at the model default, then tuning after acceptance; track response time, failures/retries, and accepted per-image cost before scaling.
Also note general limits: complex prompts can take up to about two minutes; text rendering and composition control still have boundaries. Parameters only trade fidelity, planning, and latency inside the model capability envelope—they do not remove content moderation or physics-level simulation limits. Use xhigh and max only when they clearly improve unmet quality and latency budget allows; docs do not guarantee higher tiers are better for every prompt.
Bottom line: quality answers “how finely to draw,” complexity answers “how deeply to plan.” Images 2.6 splits them and steers most edit scenarios toward low complexity in official guidance—integrators who keep “omit = max” habits instead get default-high planning depth. Set parameters explicitly and run single-variable comparisons as the docs describe.