GPT-Image-2.6 vs GPT-Image-2.5: Bytet är en enda sträng, fakturan är det inte

Att migrera från GPT-Image-2.5 till GPT-Image-2.6 är, på API-nivå, den minst dramatiska uppgradering OpenAI har släppt under hela året. Samma två slutpunkter, samma prislista, samma uppdelning mellan Flare och Sunburst. Modellsträngen ändras och inget annat behöver ändras. Det är också fällan. GPT-Image-2.6 lägger till en parameter som GPT-Image-2.5 aldrig hade – en komplexitetsratt – och att utelämna den stänger inte av den. Den har standardvärdet hög. En pipeline som byter strängen och driftsätter köper inte samma mängd arbete för samma summa pengar; den köper mer arbete, vilket är anledningen till att den första kostnadsrapporten efter en migrering kan förändras även om de publicerade priserna inte gjorde det.

Båda modellerna blev allmänt tillgängliga på samma kommersiella villkor, och det är det som gör den här jämförelsen ovanlig. Det finns inget prisargument att föra. Argumentet handlar helt och hållet om var det nya arbetet hamnar, och om din trafik är utformad så att den gynnas.

API-ytan är verkligen ett drop-in — med ett hål i sig

OpenAI lanserade GPT-Image-2.6 den 4 november 2026 som två API-modeller i stället för en, med den struktur som etablerades med 2.5. Nivån inriktad på detalj och konsekvens är GPT-Image-2.6 Sunburst; snabbhetsnivån är GPT-Image-2.6 Flare. Deras föregångare, GPT-Image-2.5 Sunburst och GPT-Image-2.5 Flare, behåller samma namn och samma förhållande till varandra.

• Modellsträngar — gpt-image-2.6-flare och gpt-image-2.6-sunburst ersätter gpt-image-2.5-flare och gpt-image-2.5-sunburst, samma namngivningslogik, en för latens och en för detalj.

• Slutpunkter — /v1/images/generations och /v1/images/edits, oförändrade. Ingen ny slutpunkt att integrera.

• Priser — 5 USD per miljon textinmatningstoken, 8 USD per miljon bildinmatningstoken, 30 USD per miljon bildutmatningstoken, med cachad indata till 1,25 USD och 2,00 USD. Byte-för-byte identisk med 2.5.

• Kvalitetsnivåer – låg, medel, hög, xhigh, max och auto. Samma stege.

• Rekommenderade storlekar – 1024×1024, 1536×1024 och 1024×1536 är fortfarande de främsta i dokumentationen, med anpassade dimensioner som accepteras i multiplar av 16 och bildförhållanden från 1:3 till 3:1.

• Hålet – 2.6 är inte tillgängligt via Batch API. Om dina bildutgifter bygger på ett nattligt jobb till halva priset, flyttas inte det jobbet ännu.

Den sista raden är den som faktiskt bryter något. Allt ovanför den är en strängersättning och en regressionskörning. Batch-gapet är en arkitektonisk blockerare för precis de arbetsbelastningar — bulk-kataloger, nattliga återfyllningar, A/B-generering i stor skala — där en rabatt på 50 % är själva anledningen till att arbetsbelastningen finns överhuvudtaget.

Komplexitetsvredet är den verkliga funktionen, och dess standardinställning är överraskningen.

Komplexitet är en ny axel som ligger vid sidan av kvalitet snarare än inuti det, och skillnaden spelar större roll än det låter. Kvalitet styr renderingen: hur många utdatatoken som går åt till bilden. Komplexitet styr planeringen: hur mycket resonemang modellen för innan den börjar rendera. Du kan be om en bild av låg kvalitet på en komplicerad scen, eller en bild av hög kvalitet på en enkel sådan, och i 2.6 är det verkligen separata förfrågningar.

Dokumentationen är tydlig med att om parametern utelämnas sätts den som standard till high. Så en anropare som porterar en 2.5-förfrågan genom att bara ändra modellnamnet och inget annat väljer i tysthet in den maximala planeringsbudgeten vid varje anrop. Det är inte en bugg – det är den förnuftiga standardinställningen för en modell vars säljargument är att tänka mer – men det innebär att den första månaden med 2.6-trafik inte är en jämförelse på lika villkor med den sista månaden med 2.5-trafik.

Det finns åtminstone en offentlig datapunkt som pekar i samma riktning. Ett praktiskt test med tre bilder som publicerades den 4 november rapporterade $0.1245 för utdata från 2.6 mot $0.0446 för samma stillbilder på 2.5 – ungefär tre gånger så mycket, enligt en prislista som inte ändrades. Tre bilder är inte ett benchmark och bör inte citeras som ett sådant; urvalet är alldeles för litet för att fastställa en multiplikator. Det den däremot gör är att demonstrera mekanismen, och mekanismen är dokumenterad: fler planeringstoken per begäran, på som standard, fakturerade till $30 per miljon.

Om du vidtar ett operativt steg från den här artikeln, vidta detta. Ställ in komplexitet explicit – medium är en rimlig första gissning för att matcha 2.5-erans beteende – och mät sedan utdatatokens per begäran före och efter. Mät inte dollar per begäran. Dollar per begäran kommer att säga dig att prislistan inte ändrades, vilket du redan visste. Tokens per begäran kommer att säga dig om modellen utför mer arbete än du bad om.

Var den påstådda 50-procentiga hastighetsökningen faktiskt hamnar

OpenAI beskriver GPT-Image-2.6 som ungefär 50 % snabbare totalt, men siffrorna per nivå är mycket mer intressanta än rubriken, och de är leverantörens egna siffror, inte oberoende uppmätta. Flare uppges ligga på cirka 2,6× sin föregångare, där renderingar av låg kvalitet blir klara på så lite som sex sekunder. Sunburst uppges ligga på cirka 1,15×.

Dessa två siffror beskriver två helt olika uppgraderingar. Om din pipeline kör Flare för iteration – utforskning av miniatyrbilder, promptjustering, vad som helst där en människa väntar på resultatet – är 2.6 ett stort steg och migreringen betalar sig enbart genom uppmärksamheten. Om din pipeline kör Sunburst för slutlig utdatakvalitet ligger en latensförbättring på 15 % inom intervallet för brus mellan körningar i de flesta hostingkonfigurationer, och hastighet är inte ett skäl att migrera överhuvudtaget.

Värt att ärligt lyfta: samma lilla praktiska test som rapporterade tokeninflationen rapporterade också att {{1}}2.6{{/1}} var långsammare än {{2}}2.5{{/2}} på sina tre bilder, vilket motsäger leverantörens påstående. Med {{3}}n=3{{/3}} är det brus, inte en vederläggning. Men det är en påminnelse om att "{{4}}50 % snabbare{{/4}}" är ett aggregerat värde från lanseringspresentationen över kvalitetsnivåer, och en verklig pipeline ser en nivå vid en kvalitetsinställning.

Ingen har fått 2,6 ännu, och 2,5 ligger fortfarande först

Det här är den del av jämförelsen som de flesta rapporteringar slätar över. Artificial Analysis, som kör sina AA-Image-T2I v2.1- och redigeringsboarder, hade ingen rad för GPT-Image-2.6 alls när man läste den 5 november 2026. Inte en låg poäng — ingen rad.

Det som de där tavlorna verkligen visar är att modellen som ersätts fortfarande vinner dem:

• Text-till-bild — GPT-Image-2.5 Sunburst (max) 1 224 Elo från 13 153 röster, första plats. GPT-Image-2.5 Flare (max) 1 207 från 12 498, andra plats. GPT Image 2 (high) 1 188, tredje plats.

• Bildredigering — GPT-Image-2.5 Sunburst (max) 1 200 av 18 370 röster, första plats. GPT-Image-2.5 Flare (max) 1 183 av 19 259, på tredje plats efter MAI-Image-2.7-Preview med 1 197.

OpenAIs lanseringsmaterial hänvisar till Design Arena för en förstaplats för 2.6 Sunburst. Det är ett verkligt påstående på en verklig resultattavla, men det är en annan bedömargrupp på en annan skala, och att en leverantör väljer den tavla som smickrar lanseringen är inte bevis för något som en köpare kan använda. Det finns ännu ingen jämförbar tredjepartssiffra baserad på röster för 2.6. Tills den finns är den försvarbara hållningen att 2.5 är den högst oberoende poängsatta bildmodellen på båda de stora resultattavlorna och att 2.6 är obevisad — bättre på de specifika sätt som OpenAI säger att den är bättre, och omätt på alla andra områden.

En migrering som ryms på en eftermiddag

Utbytet är billigt nog för att det kloka tillvägagångssättet inte är en big bang-migrering utan en kontrollerad sådan, som körs på dina egna prompter i stället för på någon annans benchmark-promptuppsättning.

Börja med att låsa komplexiteten till ett värde du själv väljer, så att ändringen är en ändring du gjort snarare än en som kommit med standardinställningarna. Kör sedan om ett par hundra riktiga prompter från dina produktionsloggar – inte de rena promptarna i dina testfixturer, utan de stökiga med stavfel och besvärliga bildförhållanden. Jämför två tal: utdatatokens per accepterad bild, och accepterade bilder per hundra försök. Det andra är där en förbättring av konsekvensen skulle synas, och det är talet som faktiskt avgör om uppgraderingen sparar pengar, eftersom en bild du kastar kostar hela tokenbudgeten och inte ger något tillbaka.

Behåll en reservväg till 2.5 för batcharbete, eftersom 2.6 ännu inte kan hantera det. Och betrakta all Sunburst-trafik som en kvalitetsfråga snarare än en hastighetsfråga – om acceptansgraden inte rör sig har du köpt en latensförbättring på 15 % och en större planeringskostnad.

När det är rätt svar att stanna kvar på 2.5

Tre fall är tydliga nog att nämna. Batch-arbetsbelastningar bör vara kvar, eftersom 2.6 inte finns i Batch API och 2.5 gör det. Sunburst-kvalitetspipelines bör vara kvar om inte acceptansgradstestet säger annat, eftersom en hastighetsökning på 1,15× inte motiverar en ändring av kostnadsmodellen. Och alla vars nuvarande acceptansgrad redan är acceptabel bör vara kvar, eftersom de nya funktionerna – SVG-export, animerad GIF, markup-styrd redigering – är additiva funktioner, inte kvalitetsförbättringar, och du behöver dem bara om du har en leverabel som kräver dem.

Uppgraderingen är en verklig sådan. Den är bara koncentrerad till Flare-latens och till nya utdataformat, och de är snävare än vad "en ny modell" antyder.

Tillgänglighet, och den besvärliga utformningen av en uppdelad migrering

OrcaRouter tillhandahåller GPT-Image-2.5 Flare och GPT-Image-2.5 Sunburst idag till listpris med 0 % påslag, så leverantörens pris är det pris du betalar, utan någon marginal ovanpå. GPT-Image-2.6 finns inte i katalogen den 5 november 2026 — en dag efter lanseringen — vilket gör det omedelbara praktiska problemet till en routingfråga snarare än en modelleringsfråga: under utvärderingen kör 2.5-trafiken på en nyckel med automatisk failover, medan 2.6-trafiken går direkt till OpenAI under ett andra avtal och en andra faktura.

Den uppdelningen är värd att planera kring snarare än att upptäcka. Kontrollera katalogen innan du binder en produktionsväg till 2.6, eftersom jämställdhet på lanseringsdagen inte är något som någon router kan lova för en modell som är tjugofyra timmar gammal. När den väl landar innebär pass-through-regeln att leverantörens pris är det du betalar samma dag – en prisändring på OpenAI:s sida skulle komma utan omförhandling på vår sida – men fram till dess är den ärliga tolkningen av situationen att 2.5 är routbar och 2.6 inte.

Vilket är ett annat argument för en migrering i eftermiddagsstorlek framför en i helgstorlek. Kör 2.5 genom routern, håll din kostnadsbaslinje stabil och lägg till 2.6 bakom en flagga när du har mätt vad standardinställningen för komplexitet gör med dina tokenantal. Modellen är inte på väg någonstans, och batch-endpointen kommer att finnas innan din nästa kvartalsvisa planeringscykel gör det.