OpenAI lanserte Images 2.6 4. november 2026 med API-modellene gpt-image-2.6-flare og gpt-image-2.6-sunburst. Changelog oppsummerer det slik: justerbar kompleksitet, SVG-generering, generering av animerte GIF-er og markup-styrt redigering for støttede GPT Image 2.5 og 2.6. Produktkunngjøringen hevder at genereringen i snitt er rundt 50 % raskere, at Flare bruker rundt seks sekunder med lav kvalitet, og at Sunburst legger vekt på detaljer og konsistens ved redigering med medium/high kvalitet. Migrering handler ikke bare om å bytte en modellstreng – det betyr å vite hva som er nytt i 2.6, hva som delvis fantes i 2.5, og om eksemplene i veiledningen stemmer med endepunkttabellen på modellsiden.

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

Hva som er endret sammenlignet med 2.5

Ifølge delen «GPT Image 2.6» i veiledningen for bildegenerering støtter både Flare og Sunburst følgende via Image API: kompleksitetskontroll, markup-styrte redigeringer, SVG-utdata og animerte GIF-utdata. De fleste kodeeksemplene i selve veiledningen viser fortsatt vanlige generering- og redigeringsflyter med modell-ID-er for GPT Image 2.5, og sier at «de følgende eksisterende eksemplene bruker GPT Image 2.5» – ikke behandle gpt-image-2.5-*-ID-ene i eksemplene som standard for 2.6.

Migreringssjekklisten i prompting-veiledningen for bilder: Lagre referanseprompter og eksempler. Brukte du 2.5 Flare før, tester du 2.6 Flare først. Brukte du 2.5 Sunburst, tester du 2.6 Sunburst først. I den første sammenligningen låser du prompter, referanser, størrelse, kvalitet og utdataformat, og lar kompleksiteten stå på modellens standardverdi. Endre bare kvalitet eller kompleksitet, én om gangen. Rull ut per arbeidsflyt i puljer, og følg med på forsinkelse, feil, nye forsøk og godkjent kostnad per bilde. Redigeringsforespørsler bør utelate den gamle input_fidelity, og GPT Image 2.6 støtter ikke reasoning.summary.

Responses API: les eksemplene i veiledningen og modellsidene hver for seg

Veiledningen for bildegenerering forklarer fortsatt bildeverktøy i samtaler over flere runder via Responses API, med 2.5-identifikatorer i modellfeltene for bildeverktøyet i eksemplene. Endepunkttabellene på modellsidene for GPT‑Image‑2.6 Flare og Sunburst markerer derimot begge v1/responses som Not supported, mens v1/images/generations og v1/images/edits er markert som Supported. Delen om 2.6 understreker også at complexity, markup, SVG og GIF leveres «via Image API».

Migreringer til produksjon bør derfor som standard koble 2.6 til generering og redigering i Image API – og ikke anta at en Responses-verktøykonfigurasjon fra 2.5-tiden bare kan få en 2.6-ID byttet inn. Hvis virksomheten er sterkt avhengig av samtalebasert redigering over flere runder, bør du verifisere på nytt med endepunkttabellen på modellsiden som fasit, i stedet for å trekke slutninger fra avsnitt i veiledningen som fortsatt bruker 2.5 med Responses som eksempel. Dette er en reell forskjell i dokumentasjonen, ikke en ordkrangel om «hvem som skrev feil» – integratører bør la modellsiden avgjøre produksjonskonfigurasjonen.

Forslag til godkjenning av migreringen

Del godkjenningen inn i tre lag. Funksjoner: Bekreft på egne forretningsdata om GIF/SVG/markup/complexity faktisk forkorter iterasjonene eller reduserer feilaktige redigeringer. Kvalitet: Sammenlign tilsvarende nivåer i 2.5 og 2.6 med de samme promptene når det gjelder tekst, identitet, produktgeometri og alfakanaler. Integrasjon: Bekreft organisasjonsverifisering, safety_identifier og feilhåndtering (ikke prøv modereringsblokkeringer på nytt i blinde), og at konfigurasjonene ikke inneholder Responses-koblinger som ikke støttes. Når det gjelder pris, er enhetsprisene for nivåene i 2.6 som er bekreftet her, like – ikke anta at «det raskere nivået er billigere».

I praksis bør du følge med på endrede vaner rundt parametere. Hvis en arbeidsflyt i 2.5 aldri satte complexity eksplisitt, vil den fortsatt utelatte verdien etter overgangen til 2.6 havne på standardverdien high, noe som kan øke forsinkelsen ved redigering og gi uønskede endringer. Det offisielle rådet for de fleste redigeringer er i stedet å sette low eksplisitt. GIF og SVG finnes bare ved generering – redigeringspipelines som forutsetter at «alle formater kan sendes frem og tilbake», vil møte veggen i 2.6. Markup dekker støttede 2.5 og 2.6, men kan ikke kombineres med mask og prompt_rewriter, så migreringsskript trenger kontroller for felt som utelukker hverandre. Prompting-veiledningen minner også om å utelate input_fidelity i redigeringsforespørsler, og at 2.6 ikke støtter reasoning.summary. Dette er vanlige feller der koden kompilerer, men feiler eller gir avvik under kjøring.

A/B-tester bør låse størrelse, kvalitet og utdataformat, bare endre modell-ID eller kompleksitet om gangen, og lagre mellomresultater. Hvis virksomheten bruker Images 2.6 både i ChatGPT-produktet og i API-et, bør du holde dem atskilt: Produktnavn ≠ modell-ID, og kvote og verifisering synkroniseres ikke automatisk. Skaler opp ved å validere feilrate og godkjent kostnad per bilde med lite trafikk før du utvider standardrutingen, og behold et vindu for tilbakerulling til 2.5 til forsinkelses- og kvalitetskurvene har stabilisert seg på egne forretningsdata.

Konklusjon: Endringene i 2.6 sammenlignet med 2.5 som kan slås fast, er hastighet og en tydeligere plassering av de to nivåene, pluss kontrollflaten som complexity, GIF, SVG og markup utgjør. Om migreringen lykkes, avhenger av sammenligninger under like forhold slik prompting-veiledningen beskriver, og av at du tar inn over deg det dokumenterte faktum at «veiledningen fortsatt viser 2.5 med Responses, mens modellsidene markerer Responses som ikke støttet for 2.6» – og deretter lar modellsiden være fasit i produksjon.