I Introducing Images 2.6 trekker OpenAI frem animerte GIF-er som et sentralt tillegg for skapere og markedsføring: Animer en maskot eller figur for merkevaren, gjør et stillbilde av et produkt om til en blikkfangende løkke, eller test figurbevegelser med animerte storyboards før videoproduksjon. API-ets Changelog (4. november 2026) registrerer også generering av animerte GIF-er for GPT‑Image‑2.6 Flare/Sunburst. Veiledningen for bildegenerering angir at animasjon bestilles ved å sette output_format til "gif" på POST /v1/images/generations.

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

Trekk opp produktgrensen først: OpenAI posisjonerer GIF som et «bevegelsesformat innenfor bildegenereringen», ikke en fullverdig videomodell som Sora. Redigeringsendepunktet (/v1/images/edits) støtter ikke GIF-utdata; strømming, delvise bilder, egendefinert output_compression og prompt_rewriter kan heller ikke kombineres med GIF. Å hevde at GIF «allerede erstatter video-API-et» eller «støtter ferdige filmer av vilkårlig lengde», går lenger enn det denne artikkelen kan bekrefte i dokumentasjonen.

Offisielle eksempler på bruksområder

Retningene på produktsiden omfatter: markedsførere og skapere som animerer merkevaremaskoter til kampanjer; reaksjons- og meme-GIF-er til sosiale medier; testing av figurbevegelser med animerte storyboards før video; og å gjøre enkle skisser om til uttrykksfulle figurer for video eller spill. Tidlige brukere som OpenArt siteres på at «én enkelt prompt kan gi GIF-er klare for sosiale medier». Kunder som Town beskrives som at de bruker API-et til å utforske personligheten til animerte figurer i arbeidssammenheng. Dette er eksempler fra kunngjøringen og kundesitater; resultatene avhenger fortsatt av prompter og parametere og bør ikke behandles som en ensartet kvalitetsgaranti eller en bransjebenchmark.

Når det gjelder prompter, foreslår veiledningen for bildeprompter: For en jevn løkke beskriver du bevegelsen som fører figuren tilbake til startposituren, og sier om kameraet beveger seg. I ett eksempel gir Sunburst med size="512x512", quality="high", standardkompleksiteten high, frame_count=9 og frame_duration_ms=200 en lyktanimasjon i løkke på rundt 1,8 sekunder. Produktsiden viser også løkker laget med prompter i sprite-ark-stil, men en API-integrasjon bør fortsatt ta utgangspunkt i output_format: "gif" og parameterne for bilderuter – ikke anta at du først må lage et stillbilde i rutenett og sette sammen rutene selv.

Forespørselsfelt og begrensninger

Ifølge dokumentasjonen for bildegenerering er de GIF-relaterte feltene:

size beskriver dimensjonene til hver ferdige bilderute. Antall ruter, rutestørrelse og antall animasjoner må holde seg innenfor modellens størrelsesgrenser og forespørselens samlede pikselbudsjett; ved overskridelse senker du frame_count, krymper rutestørrelsen eller reduserer n. Med auto velger API-et rutestørrelse innenfor modellens grenser. frame_count og frame_duration_ms gjelder bare for GIF-utdata. b64_json i svaret skal base64-dekodes og lagres som en .gif-fil. Både Flare og Sunburst kan generere GIF-er via Image API, og modellsidene oppgir animert GIF-utdata som en felles funksjon. Valget kan fortsatt følge den vanlige logikken med hastighet mot presisjon: Korte løkker til sosiale medier kan prøves med Flare først; ved høyere krav til figurkonsistens eller detaljer kan du deretter sammenligne med Sunburst.

Forsiktige grenser for bruk

For det første er GIF en funksjon på genereringssiden – ikke forvent at redigeringsendepunktet skal «gjøre et stillbilde om til en GIF». For det andre kan komplekse prompter fortsatt gi lang ventetid i bildemodeller (dokumentasjonen påpeker at komplekse prompter kan ta opptil rundt to minutter), og forespørsler om bevegelse er underlagt det samme. For det tredje gjelder innholdsmoderering og moderation-parameteren for GIF-forespørsler; ved blokkering bør du ikke prøve på nytt i blinde uten å endre prompten. For det fjerde bør du ikke beskrive GIF-funksjonen som at den «allerede erstatter video-API-et»: OpenAI har en egen produktlinje for video; GIF i Images 2.6 løser korte løkker, lett bevegelse og distribusjon i sosiale medier – ikke fortellinger i lange tagninger eller ferdige filmer med høy bildefrekvens. For det femte følger faktureringen fortsatt reglene for bildetokens på modellsiden; flere bilderuter og høyere oppløsning betyr vanligvis mer forbruk av output – mål kostnaden per element på representative prompter før lansering.

Fra et perspektiv om teknisk godkjenning bør du bygge et fast sett med prompter som dekker «løkke tilbake til startpositur» og «stillestående kamera mot kamera i bevegelse», og registrere utseende, filstørrelse og ventetid på tvers av kombinasjoner av frame_count/frame_duration_ms. Dokumentasjonen gir ingen enkelt «beste bildefrekvens»; ni ruter på to hundre millisekunder hver er bare et utgangspunkt. Hvis skjøtene i løkken er synlige, bør du heller rette formuleringene om start- og sluttpositur i prompten enn å øke antall ruter i det uendelige; flere ruter når pikselbudsjettet raskere og øker kostnaden for output-tokens.

Kort sagt setter GIF-utdata i Images 2.6 «korte bevegelser i løkke» på den formelle formatlisten i Image API. Integrer med output_format: "gif" og parameterne for bilderuter, respekter begrensningene om at redigering ikke støttes og at strømming ikke er mulig, og gjør det til et produkt uten å overdrive hva funksjonen kan.