Images 2.6 introduceert (en documenteert systematisch) twee onafhankelijke instellingen in de API: quality en complexity. Volgens de productaankondiging bepaalt quality het visuele detail en de getrouwheid van het beeld, terwijl complexity stuurt “hoeveel planning er in de scène gaat zitten”. OpenAI adviseert uitdrukkelijk: gebruik een lage complexity voor de meeste bewerkingstaken, voor snellere bewerkingen, in combinatie met het kwaliteitsniveau dat de workflow nodig heeft. De Changelog (2026-11-04) noemt instelbare complexity ook onder de hoogtepunten van de 2.6-lancering.

👉 Probeer de GPT Image 2.6 API op PoYo: prijs per afbeelding en online playground.

Wie de twee door elkaar haalt, behandelt “fijner tekenen” en “meer nadenken” als één knop. De officiële definities zeggen het tegenovergestelde: het eerste bepaalt de getrouwheid van het renderen, het tweede de diepte van de planning vóór het renderen. Houd je vast aan de oude gewoonte dat “een parameter weglaten het maximum betekent”, dan komt complexity ongemerkt op de standaardwaarde high terecht, wat bewerkingen kan vertragen en ongewenste wijzigingen kan veroorzaken.

Waarden, standaardwaarden en kosten

Volgens de gids over beeldgeneratie en de promptinggids:

Complexity aanpassen heeft geen aparte factuurregel. Een hogere complexity kan voor meer latentie en ongewenste extra wijzigingen zorgen, dus de documentatie raadt aan de resultaten per taak te vergelijken in plaats van altijd het maximum te kiezen. De productpagina merkt verder op: scènes met veel elementen of beperkingen kunnen medium of high complexity proberen; voor snelle bewerkingen passen lagere instellingen. Een lage complexity past bij gerichte wijzigingen, zoals het vervangen van een achtergrond of een straatnaambord; een hogere complexity helpt bij dichte tekst, complexe opmaak en onderlinge verhoudingen tussen objecten.

Als Flare op quality=low draait, kan het genereren volgens OpenAI in ongeveer zes seconden klaar zijn; Sunburst op medium/high kwaliteit is gepositioneerd voor meer detail en consistentere bewerkingen. Dat zijn gecombineerde effecten van modelniveau en kwaliteitsniveau; je kunt ze niet alleen aan complexity toeschrijven, en je moet niet beweren dat “het ene niveau altijd sneller is” zonder te vergelijken.

Hoe je A/B-test

De promptinggids geeft een duidelijke afstemmingsdiscipline: wijzig telkens één instelling. Zet quality vast wanneer je complexity vergelijkt; klopt de opmaak al maar is kleine tekst slecht leesbaar, vergelijk dan verschillende waarden van quality bij dezelfde complexity. De documentatie gebruikt dezelfde prompt over een voetbal-papercut met vaste size="1024x1536" en quality="medium" om te laten zien hoe Sunburst verschilt tussen lage, middelmatige en hoge complexity bij de trofee, de plaatsing van het bord “CHAMPIONS” en de details van de shirts: bij lage complexity verschijnt er een kroon op de trofee en staat er een grote banner voor het team; bij medium komen er een lauwerkrans en een embleem bij; bij high gaat het bord naar de tribune en blijft de voorgrond over aan de spelers en de plooien in de shirts. Het voorbeeld laat zien dat een hogere complexity de compositiekeuzes merkbaar verandert wanneer de prompt opmaak, tekst en stijl onderbepaald laat; zijn opmaak, tekst en stijl in de prompt al vastgelegd, dan levert een hogere complexity mogelijk bijna geen verschil op.

Voor gerichte bewerkingen is het officiële advies om op low te beginnen en te controleren of de omliggende details intact blijven. De productaankondiging en de generatiegids zijn het erover eens: gerichte wijzigingen, zoals het vervangen van een achtergrond of het aanpassen van een straatnaambord, passen bij een lagere complexity; bij dichte tekst, complexe opmaak en onderlinge verhoudingen tussen objecten loont het meer om medium/high te proberen. Bij bewerkingen met markup sluit een lage complexity meestal aan bij beperkingen in de prompt als “verander alleen het omcirkelde object” en helpt het afwijkingen buiten de cirkel te onderdrukken.

Praktische combinaties (nog binnen wat de documentatie toelaat)

Zie een “snel concept” als: Flare + quality=low (of medium) + bij bewerkingen expliciet complexity op low (want weglaten betekent standaard high en kan juist langzamer zijn). Zie een “definitieve asset” als: kies eerst Flare of Sunburst, verhoog dan quality en test apart met A/B of je complexity ook moet verhogen; ga er niet van uit dat max-kwaliteit altijd bij high complexity hoort. Bij het migreren van bestaande 2.5-workflows adviseert de promptinggids om bij de eerste vergelijking prompts, referenties, afmetingen, kwaliteit en uitvoerformaat ongewijzigd te laten, complexity op de standaardwaarde van het model te laten staan en pas na acceptatie bij te stellen; volg responstijd, fouten en nieuwe pogingen en de geaccepteerde prijs per afbeelding voordat je opschaalt.

Let ook op de algemene beperkingen: complexe prompts kunnen tot ongeveer twee minuten duren; tekstweergave en compositiebeheersing hebben nog steeds grenzen. Parameters wegen alleen getrouwheid, planning en latentie tegen elkaar af binnen wat het model aankan; ze heffen contentmoderatie of de grenzen van fysieke simulatie niet op. Gebruik xhigh en max alleen als ze duidelijk iets verbeteren wat nog niet goed genoeg is en je latentiebudget dat toelaat; de documentatie garandeert niet dat hogere niveaus voor elke prompt beter zijn.

Kortom: quality beantwoordt “hoe fijn tekenen we”, complexity beantwoordt “hoe diep plannen we”. Images 2.6 scheidt ze en stuurt in de officiële richtlijnen de meeste bewerkingsscenario’s naar een lage complexity. Wie vasthoudt aan de gewoonte “weglaten = maximum”, krijgt in plaats daarvan standaard een hoge plandiepte. Stel parameters expliciet in en vergelijk met één variabele tegelijk, zoals de documentatie beschrijft.