Images 2.6 introducerer (og dokumenterer systematisk) to uafhængige styringer i API'et: quality og complexity. Ifølge produktannonceringen styrer billedkvalitet den visuelle detalje og troværdighed, mens complexity styrer, »hvor meget planlægning der går ind i scenen«. OpenAI anbefaler udtrykkeligt: brug lav complexity til de fleste redigeringsopgaver for hurtigere redigeringer, kombineret med det kvalitetsniveau, arbejdsgangen kræver. Ændringsloggen (2026-11-04) oplister også justerbar complexity blandt højdepunkterne i 2.6-lanceringen.

👉 Prøv GPT Image 2.6-API'et på PoYo: pris pr. billede og online playground.

At forveksle de to er at behandle »tegn finere« og »tænk mere« som ét og samme håndtag. De officielle definitioner går den modsatte vej: Det første styrer renderingens troværdighed; det andet styrer planlægningsdybden før renderingen. Hvis du holder fast i den gamle vane, at »at udelade en parameter betyder maksimum«, lander complexity stille og roligt på standarden high, hvilket kan gøre redigeringer langsommere og give uønskede ændringer.

Værdier, standarder og pris

Ifølge guiden til billedgenerering og guiden til billedprompts:

Justering af complexity har ingen separat faktureringslinje. Højere complexity kan give længere svartid og uønskede ekstra ændringer, så dokumentationen anbefaler at sammenligne resultater på den konkrete opgave i stedet for altid at skrue helt op. Produktsiden bemærker desuden: Scener med mange elementer eller begrænsninger kan prøve medium eller høj complexity; hurtige redigeringer passer til lavere indstillinger. Lavere complexity egner sig til fokuserede ændringer som at skifte en baggrund eller et vejskilt; højere complexity hjælper ved tæt tekst, kompleks layout og forhold mellem objekter.

Når Flare kører med quality=low, siger OpenAI, at genereringen kan gennemføres på omkring seks sekunder; Sunburst ved medium/high kvalitet er positioneret til flere detaljer og stærkere redigeringskonsistens. Det er kombinerede effekter af modelniveau og kvalitetsniveau – de kan ikke tilskrives complexity alene, og du bør ikke påstå, at »det ene niveau altid er hurtigere«, uden at have sammenlignet.

Sådan A/B-tester du

Promptvejledningen giver en klar justeringsdisciplin: ændr én indstilling ad gangen. Fastlås quality, når du sammenligner complexity; hvis layoutet allerede er korrekt, men lille tekst er svær at læse, så sammenlign forskellige quality-værdier ved samme complexity. Dokumentationen bruger det samme prompt med et fodboldmotiv i papirklip med fast size="1024x1536" og quality="medium" til at vise Sunbursts forskelle mellem lav/middel/høj complexity i pokal, placering af skiltet »CHAMPIONS« og trøjedetaljer: Ved lav complexity optræder en krone på pokalen, og et stort banner står foran holdet; middel tilføjer laurbær og våbenskjold; høj flytter skiltet op på tribunen og overlader forgrunden til spillere og trøjefolder. Eksemplet viser, at når prompten lader layout, tekst og stil være underspecificerede, ændrer højere complexity kompositionsbeslutningerne markant; når layout, tekst og stil allerede er låst fast i prompten, viser højere complexity måske næsten ingen forskel.

Til målrettede redigeringer er den officielle anbefaling at starte på low og kontrollere, at omgivende detaljer forbliver intakte. Produktannonceringen og generationsguiden er enige: Fokuserede ændringer som udskiftning af baggrund eller redigering af vejskilte passer til lavere complexity; tæt tekst, kompleks layout og forhold mellem objekter er der, hvor medium/high er mere værd at prøve. Ved markup-redigeringer passer lav complexity normalt godt sammen med promptbegrænsningen »ændr kun det indcirklede objekt« og hjælper med at dæmpe afdrift uden for cirklen.

Praktiske kombinationer (stadig inden for det dokumenterede)

Betragt et »hurtigt udkast« som: Flare + quality=low (eller medium) + udtrykkeligt sat complexity til low ved redigeringer (fordi udeladelse giver standarden high og faktisk kan være langsommere). Betragt et »endeligt asset« som: Når du har valgt Flare eller Sunburst, så hæv quality, og A/B-test separat, om complexity skal hæves – gå ikke ud fra, at kvaliteten max nødvendigvis skal kobles med high complexity. Når du migrerer eksisterende 2.5-arbejdsgange, foreslår promptvejledningen, at du ved den første sammenligning holder prompts, referencer, størrelse, kvalitet og outputformat uændrede, lader complexity stå på modellens standard og først justerer efter godkendelsen; følg svartid, fejl/genforsøg og godkendt pris pr. billede, før du skalerer op.

Bemærk også de generelle grænser: Komplekse prompts kan tage op til omkring to minutter; tekstrendering og kompositionskontrol har stadig grænser. Parametre afvejer kun troværdighed, planlægning og svartid inden for modellens kapacitetsramme – de fjerner ikke indholdsmoderering eller grænser for fysiksimulering. Brug xhigh og max kun, når de tydeligt forbedrer en uopfyldt kvalitet, og svartidsbudgettet tillader det; dokumentationen garanterer ikke, at højere niveauer er bedre for ethvert prompt.

Kort sagt: quality svarer på »hvor fint skal der tegnes«, complexity svarer på »hvor dybt skal der planlægges«. Images 2.6 adskiller dem og styrer de fleste redigeringsscenarier mod lav complexity i den officielle vejledning – integratorer, der beholder vanen »udeladt = maks«, får i stedet planlægningsdybden high som standard. Sæt parametre udtrykkeligt, og kør sammenligninger med én variabel ad gangen, som dokumentationen beskriver.