Images 2.6 introduserer (og dokumenterer systematisk) to uavhengige kontroller i API-et: quality og complexity. Ifølge produktkunngjøringen styrer bildekvaliteten visuelle detaljer og gjengivelsestrohet, mens complexity styrer «hvor mye planlegging som går inn i scenen». OpenAI anbefaler eksplisitt å bruke lav kompleksitet for de fleste redigeringsoppgaver for å få raskere redigeringer, kombinert med det kvalitetsnivået arbeidsflyten krever. Changelog (2026-11-04) nevner også justerbar kompleksitet blant høydepunktene i 2.6-lanseringen.

👉 Prøv GPT Image 2.6 API på PoYo: pris per bilde og nettbasert playground.

Hvis du blander dem sammen, behandler du «tegne finere» og «tenke mer» som én og samme bryter. De offisielle definisjonene sier det motsatte: Den første styrer gjengivelseskvaliteten, den andre planleggingsdybden før rendering. Hvis du holder fast ved den gamle vanen om at «en utelatt parameter betyr maksimum», havner complexity stille og rolig på standardverdien high, noe som kan gjøre redigeringer tregere og føre til uønskede endringer.

Verdier, standardverdier og kostnad

Ifølge veiledningen for bildegenerering og prompting-veiledningen for bilder:

Justering av kompleksitet har ingen egen faktureringslinje. Høyere kompleksitet kan gi mer forsinkelse og uønskede ekstraendringer, så dokumentasjonen anbefaler å sammenligne resultater på den konkrete oppgaven i stedet for alltid å skru alt til maks. Produktsiden påpeker også at scener med mange elementer eller begrensninger kan prøve medium eller high kompleksitet, mens raske redigeringer passer best med lavere innstillinger. Lavere kompleksitet passer for avgrensede endringer som å bytte bakgrunn eller et gateskilt, mens høyere kompleksitet hjelper ved tett tekst, kompleks layout og relasjoner mellom objekter.

Når Flare kjøres med quality=low, sier OpenAI at genereringen kan bli ferdig på rundt seks sekunder. Sunburst med kvaliteten medium/high er posisjonert for flere detaljer og bedre konsistens ved redigering. Dette er samlede effekter av modellnivå og kvalitetsnivå – de kan ikke tilskrives kompleksitet alene, og du bør ikke påstå at «ett nivå alltid er raskere» uten å ha sammenlignet.

Slik A/B-tester du

Prompting-veiledningen gir en tydelig disiplin for justering: endre én innstilling om gangen. Lås quality når du sammenligner kompleksitet. Hvis layouten allerede er riktig, men liten tekst er vanskelig å lese, sammenligner du ulike quality-verdier med samme kompleksitet. Dokumentasjonen bruker den samme fotballprompten i papirklippstil med fast size="1024x1536" og quality="medium" for å vise hvordan Sunburst varierer mellom low/medium/high kompleksitet når det gjelder pokalen, plasseringen av «CHAMPIONS»-skiltet og detaljene i draktene: Med lav kompleksitet dukker det opp en krone på pokalen, og et stort banner står foran laget. Medium legger til laurbær og klubbmerke. High flytter skiltet opp på tribunen og overlater forgrunnen til spillerne og foldene i draktene. Eksemplet viser at når prompten lar layout, tekst og stil være underspesifisert, endrer høyere kompleksitet komposisjonsvalgene merkbart. Når layout, tekst og stil allerede er låst i prompten, kan høyere kompleksitet gi nesten ingen forskjell.

For målrettede redigeringer er det offisielle rådet å starte på low og sjekke at detaljene rundt forblir intakte. Produktkunngjøringen og genereringsveiledningen sier det samme: Avgrensede endringer som bakgrunnsbytte eller endring av gateskilt passer for lavere kompleksitet, mens tett tekst, kompleks layout og relasjoner mellom objekter er der medium/high er mer verdt å prøve. Ved markup-redigering stemmer lav kompleksitet som regel godt med promptbegrensninger av typen «endre bare det innringede objektet», og hjelper med å hindre avvik utenfor sirkelen.

Praktiske kombinasjoner (fortsatt innenfor det dokumentasjonen gir grunnlag for)

Tenk på «raskt utkast» som Flare + quality=low (eller medium) + complexity eksplisitt satt til low for redigeringer (fordi en utelatt verdi blir high og faktisk kan være tregere). Tenk på «ferdig ressurs» som: Når du har valgt Flare eller Sunburst, øker du quality og A/B-tester separat om du skal øke kompleksiteten – ikke anta at max-kvalitet må kombineres med high kompleksitet. Når du migrerer eksisterende 2.5-arbeidsflyter, foreslår prompting-veiledningen at du beholder prompter, referanser, størrelse, kvalitet og utdataformat uendret i den første sammenligningen, lar kompleksiteten stå på modellens standardverdi, og justerer først etter godkjenning. Følg med på responstid, feil/nye forsøk og godkjent kostnad per bilde før du skalerer opp.

Merk også de generelle begrensningene: Komplekse prompter kan ta opptil rundt to minutter, og tekstgjengivelse og komposisjonskontroll har fortsatt sine grenser. Parameterne veier bare kvalitet, planlegging og forsinkelse mot hverandre innenfor modellens kapasitet – de fjerner ikke innholdsmoderering eller begrensninger i fysisk simulering. Bruk xhigh og max bare når de tydelig forbedrer kvalitet som ellers ikke holder mål, og forsinkelsesbudsjettet tillater det. Dokumentasjonen garanterer ikke at høyere nivåer er bedre for alle prompter.

Konklusjon: quality svarer på «hvor fint skal det tegnes», complexity svarer på «hvor grundig skal det planlegges». Images 2.6 skiller dem og styrer i den offisielle veiledningen de fleste redigeringsscenarier mot lav kompleksitet – integratører som holder fast ved vanen «utelatt = maks», får i stedet høy planleggingsdybde som standard. Sett parameterne eksplisitt, og kjør sammenligninger med én variabel om gangen slik dokumentasjonen beskriver.