OpenAI bracht Images 2.6 op 4 november 2026 uit, met de API-modellen gpt-image-2.6-flare en gpt-image-2.6-sunburst. De samenvatting uit de Changelog: instelbare complexity, het genereren van SVG, het genereren van geanimeerde GIF’s en bewerken met markup voor ondersteunde GPT Image-modellen 2.5 en 2.6. De productaankondiging noemt gemiddeld ongeveer 50% sneller genereren, Flare in ongeveer zes seconden bij lage kwaliteit en Sunburst met nadruk op detail en consistente bewerkingen bij medium/high kwaliteit. Migreren is niet alleen een modelnaam vervangen: je moet weten wat er nieuw is in 2.6, wat in 2.5 al gedeeltelijk beschikbaar was en of de voorbeelden in de gids overeenkomen met de Endpoints-tabel op de modelpagina.

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

Verschillen in mogelijkheden ten opzichte van 2.5

Volgens het onderdeel “GPT Image 2.6” in de gids over beeldgeneratie ondersteunen Flare en Sunburst allebei via de Image API: besturing van complexity, bewerken met markup, SVG-uitvoer en geanimeerde GIF-uitvoer. De meeste codevoorbeelden in de hoofdtekst van de gids tonen nog steeds de gangbare generatie- en bewerkingsflows met model-ID’s van GPT Image 2.5 en vermelden dat “de volgende bestaande voorbeelden GPT Image 2.5 gebruiken”. Beschouw de gpt-image-2.5-*-ID’s uit de voorbeelden dus niet als de standaardwaarden voor 2.6.

De migratiechecklist uit de promptinggids: bewaar baseline-prompts en voorbeelden; had je eerder 2.5 Flare, test dan eerst 2.6 Flare; had je eerder 2.5 Sunburst, test dan eerst 2.6 Sunburst; zet bij de eerste vergelijking prompts, referenties, afmetingen, kwaliteit en uitvoerformaat vast en laat complexity op de standaardwaarde van het model staan; wijzig telkens maar één ding, quality of complexity; rol workflow voor workflow in batches uit en volg latentie, fouten, nieuwe pogingen en de geaccepteerde prijs per afbeelding. Laat in bewerkingsrequests het verouderde input_fidelity weg; GPT Image 2.6 ondersteunt reasoning.summary niet.

Responses API: lees de voorbeelden in de gids en de modelpagina’s apart

De gids over beeldgeneratie legt nog steeds uit hoe je via de Responses API beeldtools voor gesprekken over meerdere rondes gebruikt, met 2.5-identifiers in de modelvelden van de voorbeelden voor de beeldtool. De Endpoints-tabellen op de modelpagina’s van GPT‑Image‑2.6 Flare en Sunburst markeren daarentegen allebei v1/responses als Not supported, terwijl v1/images/generations en v1/images/edits als Supported staan. Het 2.6-onderdeel benadrukt ook dat complexity, markup, SVG en GIF “via de Image API” worden geboden.

Productiemigraties moeten daarom standaard 2.6 aansluiten op de generaties en edits van de Image API, en er niet van uitgaan dat een Responses-toolconfiguratie uit de 2.5-tijd zomaar met een 2.6-ID kan worden vervangen. Hangt je bedrijf sterk af van bewerken in gesprekken over meerdere rondes, controleer dan opnieuw aan de hand van de Endpoints-tabel op de modelpagina als gezaghebbende bron, in plaats van te extrapoleren uit alinea’s in de gids die nog 2.5 Responses als voorbeeld gebruiken. Dat is een echt verschil in de documentatie, geen woordenstrijd over “wie zich verschreven heeft”; integrators moeten hun productieconfiguratie laten afhangen van de modelpagina.

Suggesties voor migratieacceptatie

Verdeel de acceptatie over drie lagen. Mogelijkheden: controleer op je eigen bedrijfsdata of GIF/SVG/markup/complexity de iteratie echt verkorten of foutieve bewerkingen verminderen. Kwaliteit: vergelijk de overeenkomstige niveaus van 2.5 en 2.6 met dezelfde prompts op tekst, identiteit, productgeometrie en alfakanalen. Integratie: controleer organisatieverificatie, safety_identifier en foutafhandeling (probeer moderatieblokkades niet blindelings opnieuw), en zorg dat configuraties geen niet-ondersteunde Responses-koppelingen bevatten. Wat prijzen betreft, komen de eenheidsprijzen van de 2.6-niveaus die hier zijn gecontroleerd overeen; ga er niet van uit dat “het snellere niveau goedkoper is”.

Let in de praktijk op veranderingen in parametergewoonten. Heeft een 2.5-workflow complexity nooit expliciet ingesteld, dan komt die na de overstap naar 2.6 bij weglaten op de standaardwaarde high, wat de latentie van bewerkingen kan verlengen en ongewenste wijzigingen kan toevoegen; het officiële advies voor de meeste bewerkingen is juist om expliciet low in te stellen. GIF en SVG bestaan alleen bij generaties: bewerkingspipelines die ervan uitgaan dat “elk formaat heen en terug kan”, lopen op 2.6 tegen een muur aan. Markup dekt ondersteunde 2.5- en 2.6-modellen, maar sluit mask en prompt_rewriter uit; migratiescripts hebben controles op onderling uitsluitende velden nodig. De promptinggids herinnert er ook aan: laat input_fidelity weg in bewerkingsrequests; 2.6 ondersteunt reasoning.summary niet. Dit zijn veelvoorkomende valkuilen die wel compileren maar tijdens runtime falen of afwijken.

Laat A/B-tests afmetingen, kwaliteit en uitvoerformaat vastzetten, telkens alleen de model-ID of complexity wijzigen en tussentijdse voorbeelden bewaren. Gebruikt het bedrijf zowel Images 2.6 in het ChatGPT-product als de API, boek dan apart: productnaam ≠ model-ID, en quotum en verificatie worden niet automatisch gesynchroniseerd. Schaal op door eerst met weinig verkeer het faalpercentage en de geaccepteerde prijs per afbeelding te valideren voordat je de standaardroutering uitbreidt; houd een terugvalperiode voor 2.5 aan totdat de curves voor latentie en kwaliteit op je eigen bedrijfsdata stabiliseren.

Kortom: de aantoonbare verschillen tussen 2.6 en 2.5 zijn de snelheid en de sterkere positionering in twee niveaus, plus de besturingsmogelijkheden van complexity, GIF, SVG en markup. Een geslaagde migratie hangt af van vergelijkingen onder gelijke omstandigheden volgens de promptinggids, en van het onder ogen zien van het documentatiefeit dat “de gids nog 2.5 Responses toont terwijl de modelpagina’s Responses voor 2.6 als niet ondersteund markeren”, waarna je de modelpagina als gezaghebbend voor productie behandelt.