No Introducing Images 2.6, a OpenAI apresenta o GIF animado como um dos principais acrescentos para criadores e para o marketing: animar a mascote ou uma personagem de uma marca, transformar uma foto de produto num loop que prende a atenção, ou testar o movimento de personagens em storyboards animados antes da produção de vídeo. O Changelog da API (4 de novembro de 2026) regista igualmente a geração de GIF animado para o GPT‑Image‑2.6 Flare/Sunburst. O guia de geração de imagens indica que a animação se pede definindo output_format como "gif" em POST /v1/images/generations.

👉 Experimenta a API GPT Image 2.6 no PoYo: preço por imagem e playground online.

Convém começar por traçar a fronteira do produto: a OpenAI posiciona o GIF como um “formato de movimento dentro do caminho de geração de imagens”, e não como um modelo de vídeo completo como o Sora. O endpoint de edições (/v1/images/edits) não suporta saída GIF; streaming, imagens parciais, output_compression personalizado e prompt_rewriter também não podem ser combinados com GIF. Afirmar que o GIF “já substitui a API de vídeo” ou que “suporta filmes finalizados de duração arbitrária” vai além do que este artigo consegue verificar na documentação.

Casos de utilização de exemplo oficiais

As direções indicadas na página do produto incluem: profissionais de marketing e criadores a animar mascotes de marca para campanhas; GIFs de reação e de memes para as redes sociais; testar o movimento de personagens com storyboards animados antes do vídeo; transformar esboços simples em personagens expressivas para vídeo ou jogos. Utilizadores pioneiros como a OpenArt são citados a sublinhar que “um único prompt pode produzir GIFs prontos para as redes sociais”. Clientes como a Town são descritos a usar a API para explorar a personalidade de personagens animadas em contextos de trabalho. São exemplos do anúncio e citações de clientes; os resultados continuam a depender dos prompts e dos parâmetros e não devem ser tomados como garantia uniforme de qualidade nem como referência do setor.

Quanto ao prompting, o guia de prompting de imagens sugere: para um loop suave, descreve o percurso que devolve a personagem à pose inicial e indica se a câmara se move. Num exemplo, o Sunburst com size="512x512", quality="high", complexity high por predefinição, frame_count=9 e frame_duration_ms=200 produz um loop de animação de uma lanterna com cerca de 1,8 segundos. A página do produto mostra também loops pedidos ao estilo de sprite sheet, mas a integração pela API deve continuar a basear-se em output_format: "gif" e nos parâmetros de frames; não assumas que tens de gerar primeiro uma imagem em grelha e montar tu os frames.

Campos do pedido e limites

Segundo a documentação de geração de imagens, os campos relacionados com GIF são:

O size descreve as dimensões de cada frame concluído. O número de frames, o tamanho dos frames e o número de animações têm de caber nos limites de tamanho do modelo e no orçamento total de píxeis do pedido; se for excedido, reduz o frame_count, diminui o tamanho dos frames ou baixa o n. Com auto, a API escolhe o tamanho dos frames dentro dos limites do modelo. frame_count e frame_duration_ms aplicam-se apenas à saída GIF. O b64_json da resposta deve ser descodificado de base64 e guardado como ficheiro .gif. Tanto o Flare como o Sunburst podem gerar GIFs através da Image API; as páginas dos modelos indicam a saída GIF animada como capacidade partilhada. A escolha pode seguir a lógica habitual de velocidade vs precisão: para loops curtos para as redes sociais, experimenta primeiro o Flare; se precisares de maior consistência das personagens ou de mais detalhe, compara depois com o Sunburst.

Limites de utilização prudente

Primeiro, o GIF é uma capacidade do lado das generations: não esperes que o endpoint de edições “transforme uma imagem estática num GIF”. Segundo, prompts complexos podem continuar a ter latência elevada nos modelos de imagem (a documentação refere que os prompts complexos podem demorar até cerca de dois minutos); os pedidos de movimento estão sujeitos ao mesmo. Terceiro, a moderação de conteúdo e o parâmetro moderation aplicam-se aos pedidos de GIF; quando um pedido é bloqueado, não repitas às cegas sem alterar o prompt. Quarto, não escrevas que a capacidade de GIF “já substitui a API de vídeo”: a OpenAI mantém uma linha de produto de vídeo separada; o GIF do Images 2.6 resolve loops curtos, movimento leve e distribuição nas redes sociais, e não narrativas em plano longo nem filmes finalizados com frame rate elevado. Quinto, a faturação continua a seguir as regras de tokens de imagem das páginas dos modelos; mais frames e maior resolução significam normalmente mais consumo de saída, por isso mede o custo por item com prompts representativos antes do lançamento.

Do ponto de vista da aceitação em engenharia, cria um conjunto fixo de prompts que cubra “voltar à pose inicial” e “câmara parada vs câmara em movimento”, e regista o aspeto, o tamanho do ficheiro e a latência em várias combinações de frame_count/frame_duration_ms. A documentação não indica uma única “melhor frame rate”; nove frames de duzentos milissegundos cada são apenas um ponto de partida. Se as junções do loop forem visíveis, dá preferência a corrigir a descrição da pose inicial e final no prompt em vez de aumentar indefinidamente o número de frames; mais frames chegam mais depressa ao limite do orçamento de píxeis e aumentam o custo em tokens de saída.

Em resumo, a saída GIF do Images 2.6 põe o “movimento curto em loop” na lista formal de formatos da Image API. Integra com output_format: "gif" e os parâmetros de frames, respeita os limites de edições não suportadas e de ausência de streaming, e transforma-o em produto sem exagerar a capacidade.