GPT-Image-2.6 vs GPT-Image-2.5: de switch is één string, de factuur niet

Migreren van GPT-Image-2.5 naar GPT-Image-2.6 is, op API-niveau, de minst dramatische upgrade die OpenAI dit jaar heeft uitgebracht. Dezelfde twee endpoints, dezelfde tariefkaart, dezelfde Flare-versus-Sunburst-verdeling. De modelstring verandert en niets anders hoeft dat te doen. Dat is ook de valkuil. GPT-Image-2.6 voegt één parameter toe die GPT-Image-2.5 nooit had — een complexiteitsknop — en als je die weglaat, wordt hij niet uitgeschakeld. Hij staat standaard op hoog. Een pipeline die de string vervangt en uitrolt, koopt niet dezelfde hoeveelheid werk voor hetzelfde geld; hij koopt meer werk, en daarom kan het eerste kostenrapport na een migratie afwijken, zelfs als de gepubliceerde tarieven dat niet deden.

Beide modellen werden algemeen beschikbaar onder dezelfde commerciële voorwaarden, en dat maakt deze vergelijking ongebruikelijk. Er valt geen discussie over prijs te voeren. De discussie gaat volledig over waar het nieuwe werk naartoe gaat, en of je verkeer zodanig is vormgegeven dat het ervan profiteert.

Het API-oppervlak is echt een drop-in — met één gat erin.

OpenAI heeft GPT-Image-2.6 op 4 november 2026 uitgebracht als twee API-modellen in plaats van één, waarmee het de structuur voortzet die het met 2.5 had vastgesteld. De op detail en consistentie gerichte variant is GPT-Image-2.6 Sunburst; de snelle variant is GPT-Image-2.6 Flare. Hun voorgangers, GPT-Image-2.5 Sunburst en GPT-Image-2.5 Flare, behouden dezelfde namen en dezelfde onderlinge verhouding.

• Modelstrings — gpt-image-2.6-flare en gpt-image-2.6-sunburst vervangen gpt-image-2.5-flare en gpt-image-2.5-sunburst, dezelfde naamgevingslogica, één voor latency en één voor detail.

• Eindpunten — /v1/images/generations en /v1/images/edits, ongewijzigd. Geen nieuw eindpunt om te integreren.

• Tarieven — $5 per miljoen tekstinvoertokens, $8 per miljoen afbeeldingsinvoertokens, $30 per miljoen afbeeldingsuitvoertokens, met gecachte invoer tegen $1,25 en $2,00. Byte voor byte identiek aan 2.5.

Kwaliteitsniveaus — laag, gemiddeld, hoog, xhoog, max en auto. Dezelfde ladder.

• Aanbevolen formaten — 1024×1024, 1536×1024 en 1024×1536 staan nog steeds bovenaan in de documentatie, waarbij aangepaste afmetingen worden geaccepteerd in veelvouden van 16 en beeldverhoudingen van 1:3 tot 3:1.

• Het gat — 2.6 is niet beschikbaar via de Batch API. Als je image-uitgaven afhangen van een nightly job tegen de halve prijs, dan komt die job voorlopig niet in beweging.

Die laatste regel is degene die echt iets breekt. Alles daarboven is een stringvervanging en een regressierun. De batchkloof is een architectonische blokkade voor precies de workloads — bulkcatalogi, nachtelijke backfills, grootschalige A/B-generatie — waarbij een korting van 50% de reden is dat de workload überhaupt bestaat.

De complexiteitsregelaar is het echte kenmerk, en de verrassing zit in de standaardinstelling ervan.

Complexiteit is een nieuwe as die naast kwaliteit staat in plaats van erbinnen, en dat onderscheid is belangrijker dan het klinkt. Kwaliteit bepaalt de render: hoeveel outputtokens er in de afbeelding gaan. Complexiteit bepaalt de planning: hoeveel redeneerwerk het model doet voordat het begint te renderen. Je kunt om een afbeelding van lage kwaliteit van een ingewikkelde scène vragen, of om een afbeelding van hoge kwaliteit van een eenvoudige, en in 2.6 zijn dat echt afzonderlijke verzoeken.

De documentatie is expliciet: als je de parameter weglaat, wordt deze standaard op high gezet. Een aanroeper die een 2.5-verzoek overzet door alleen de modelnaam te wijzigen en niets anders, kiest dus stilzwijgend bij elke aanroep voor het maximale planningsbudget. Dat is geen bug — het is de verstandige standaard voor een model waarvan het verkoopargument is dat het meer nadenkt — maar het betekent wel dat het verkeer van de eerste maand met 2.6 geen gelijkwaardige vergelijking is met het verkeer van de laatste maand met 2.5.

Er is ten minste één openbaar gegeven dat in dezelfde richting wijst. Een praktijktest met drie afbeeldingen, gepubliceerd op 4 november, meldde $0,1245 voor 2.6-output tegenover $0,0446 voor dezelfde stills op 2.5 — ruwweg drie keer zoveel, op een tariefkaart die niet is gewijzigd. Drie afbeeldingen vormen geen benchmark en moeten niet als zodanig worden aangehaald; de steekproef is veel te klein om een vermenigvuldigingsfactor vast te stellen. Wat het wel doet, is het mechanisme demonstreren, en het mechanisme is gedocumenteerd: meer planningstokens per verzoek, standaard ingeschakeld, gefactureerd tegen $30 per miljoen.

Als je één operationele stap uit dit artikel meeneemt, laat het dan deze zijn. Stel complexiteit expliciet in — medium is een redelijke eerste gok om gedrag uit het 2.5-tijdperk te evenaren — en meet daarna outputtokens per verzoek vóór en na. Meet geen dollars per verzoek. Dollars per verzoek vertellen je dat de tariefkaart niet is veranderd, wat je al wist. Tokens per verzoek vertellen je of het model meer werk doet dan je hebt gevraagd.

Waar de beweerde versnelling van 50% in werkelijkheid op neerkomt

OpenAI beschrijft GPT-Image-2.6 als overall ongeveer 50% sneller, maar de cijfers per tier zijn veel interessanter dan de kop, en het zijn de eigen cijfers van de leverancier, niet onafhankelijk gemeten. Flare zou ongeveer 2,6× zo snel zijn als zijn voorganger, waarbij renders van lage kwaliteit in slechts zes seconden worden voltooid. Sunburst zou ongeveer 1,15× zijn.

Die twee getallen beschrijven twee totaal verschillende upgrades. Als je pipeline Flare draait voor iteratie — thumbnailverkenning, prompt tuning, alles waarbij een mens op het resultaat wacht — dan is 2.6 een enorme sprong vooruit, en de migratie verdient zichzelf alleen al terug in aandacht. Als je pipeline Sunburst draait voor de uiteindelijke outputkwaliteit, valt een latencyverbetering van 15% binnen de run-to-run-ruis op de meeste hostingopstellingen, en snelheid is helemaal geen reden om te migreren.

Eerlijk gezegd de moeite waard om te vermelden: dezelfde kleine praktijktest die de tokeninflatie meldde, meldde ook dat 2.6 langzamer was dan 2.5 op zijn drie afbeeldingen, wat de bewering van de leverancier tegenspreekt. Met n=3 is dat ruis, geen weerlegging. Maar het is een herinnering dat "50% sneller" een aggregatie uit een lanceerpresentatie over kwaliteitsniveaus heen is, en een echte pipeline ziet één niveau bij één kwaliteitsinstelling.

Niemand heeft nog 2,6 gescoord, en 2,5 staat nog steeds op de eerste plaats.

Dit is het deel van de vergelijking dat de meeste verslaggeving verdoezelt. Artificial Analysis, dat zijn AA-Image-T2I v2.1- en bewerkingsboards draait, had helemaal geen rij voor GPT-Image-2.6 toen er op 5 november 2026 werd gekeken. Geen lage score — geen rij.

Wat die borden wel laten zien, is dat het model dat wordt vervangen ze nog steeds wint:

• Tekst-naar-afbeelding — GPT-Image-2.5 Sunburst (max) 1.224 Elo uit 13.153 stemmen, eerste. GPT-Image-2.5 Flare (max) 1.207 uit 12.498, tweede. GPT Image 2 (high) 1.188, derde.

• Beeldbewerking — GPT-Image-2.5 Sunburst (max) 1.200 van 18.370 stemmen, eerste. GPT-Image-2.5 Flare (max) 1.183 van 19.259, derde achter MAI-Image-2.7-Preview met 1.197.

In het lanceringsmateriaal van OpenAI wordt Design Arena aangehaald als bewijs voor een eerste plaats voor 2.6 Sunburst. Dat is een echte bewering op een echt scorebord, maar het is een andere groep beoordelaars op een andere schaal, en dat een leverancier het bord kiest dat gunstig uitvalt voor zijn release, is geen bewijs waar een koper iets aan heeft. Het vergelijkbare cijfer op basis van stemmen van derden voor 2.6 bestaat nog niet. Totdat dat er is, is de verdedigbare stelling dat 2.5 het beeldmodel met de hoogste onafhankelijke score is op beide grote scoreborden en dat 2.6 onbewezen is — beter op de specifieke punten waarop OpenAI zegt dat het beter is, en overal elders ongemeten.

Een migratie die in een middag past

De overstap is goedkoop genoeg dat de verstandige aanpak geen big-bang-migratie is, maar een afgewogen aanpak, uitgevoerd op je eigen prompts in plaats van op iemands benchmark-promptset.

Begin met de complexiteit vast te zetten op een waarde die je zelf hebt gekozen, zodat de verandering een verandering is die je zelf hebt aangebracht en niet een die standaard is komen binnenvallen. Voer vervolgens een paar honderd echte prompts uit je productielogs opnieuw uit — niet de schone prompts uit je testfixtures, maar de rommelige met de typefouten en de onhandige beeldverhoudingen. Vergelijk twee getallen: outputtokens per geaccepteerde afbeelding, en geaccepteerde afbeeldingen per honderd pogingen. Het tweede is waar een verbetering in consistentie zichtbaar zou worden, en het is het getal dat daadwerkelijk bepaalt of de upgrade geld bespaart, want een afbeelding die je weggooit kost het volledige tokenbudget en levert niets op.

Houd een fallbackpad naar 2.5 voor batchwerk, omdat 2.6 dit nog niet kan bedienen. En behandel al het Sunburst-verkeer als een kwaliteitskwestie in plaats van een snelheidskwestie — als de acceptatiegraad niet verandert, heb je een latentieverbetering van 15% en een grotere planningsrekening gekocht.

Wanneer op 2.5 blijven het juiste antwoord is

Drie gevallen zijn duidelijk genoeg om te benoemen. Batchworkloads moeten blijven, omdat 2.6 niet op de Batch API zit en 2.5 wel. Pipelines voor Sunburst-kwaliteit moeten blijven, tenzij de acceptrate-test anders uitwijst, omdat een snelheidswinst van 1,15× niet opweegt tegen een wijziging van het kostenmodel. En iedereen wiens huidige acceptatiegraad al acceptabel is, moet blijven, omdat de nieuwe mogelijkheden — SVG-export, geanimeerde GIF, markup-gestuurde bewerking — aanvullende functies zijn, geen kwaliteitsverbeteringen, en je hebt ze alleen nodig als je een deliverable hebt die ze vereist.

De upgrade is echt. Hij is alleen geconcentreerd in Flare-latentie en in nieuwe uitvoerformaten, en die zijn beperkter dan "een nieuw model" suggereert.

Beschikbaarheid, en de onhandige vorm van een gesplitste migratie

OrcaRouter levert GPT-Image-2.5 Flare en GPT-Image-2.5 Sunburst vandaag tegen lijstprijs met 0% opslag, dus het tarief van de provider is het tarief dat u betaalt, zonder dat er nog een marge bovenop komt. GPT-Image-2.6 staat per 5 november 2026 niet in de catalogus — een dag na de lancering — waardoor het onmiddellijke praktische probleem er een van routering is in plaats van modellering: tijdens de bake-off draait 2.5-verkeer op één sleutel met automatische failover, terwijl 2.6-verkeer rechtstreeks naar OpenAI gaat onder een tweede contract en een tweede factuur.

Het is de moeite waard om die splitsing in je planning mee te nemen in plaats van er pas achter te komen. Controleer de catalogus voordat je een productiepad aan 2.6 toewijst, want pariteit op de lanceerdag is niet iets wat een router kan beloven voor een model dat vierentwintig uur oud is. Wanneer het eenmaal zover is, betekent de pass-through-regel dat het tarief van de leverancier is wat je dezelfde dag betaalt — een prijswijziging aan de kant van OpenAI zou komen zonder heronderhandeling aan onze kant — maar tot die tijd is de eerlijke lezing van de situatie dat 2.5 routeerbaar is en 2.6 niet.

Wat weer een argument is om de migratie in een middag te doen in plaats van in een weekend. Laat 2.5 door de router lopen, houd je kostenbaseline stabiel en voeg 2.6 achter een flag toe zodra je hebt gemeten wat de standaardinstelling voor complexiteit met je tokentellingen doet. Het model gaat nergens heen, en de batch-endpoint is er eerder dan je volgende kwartaalplanningscyclus.