A OpenAI lançou o Images 2.6 a 4 de novembro de 2026, com os modelos de API gpt-image-2.6-flare e gpt-image-2.6-sunburst. O resumo do Changelog: complexity ajustável, geração de SVG, geração de GIF animado e edição guiada por markup nos GPT Image 2.5 e 2.6 suportados. O anúncio do produto indica uma geração cerca de 50% mais rápida em média, o Flare com cerca de seis segundos em qualidade baixa e o Sunburst com ênfase no detalhe e na consistência das edições com qualidade medium/high. Migrar não é apenas mudar uma string de modelo: é saber o que é novo no 2.6, o que já estava parcialmente disponível no 2.5 e se os exemplos do corpo do guia coincidem com a tabela de Endpoints da página do modelo.

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

Diferenças de capacidades face ao 2.5

Segundo a secção “GPT Image 2.6” do guia de geração de imagens, o Flare e o Sunburst suportam ambos, através da Image API: controlo de complexity, edições guiadas por markup, saída SVG e saída GIF animada. A maioria dos exemplos de código do corpo do guia continua a demonstrar os fluxos comuns de geração e de edição com IDs de modelo do GPT Image 2.5 e indica que “os exemplos existentes que se seguem usam o GPT Image 2.5”; não trates os IDs de exemplo gpt-image-2.5-* como predefinições do 2.6.

A lista de verificação de migração do guia de prompting de imagens: guarda prompts e amostras de referência; quem usava o 2.5 Flare → testa primeiro o 2.6 Flare; quem usava o 2.5 Sunburst → testa primeiro o 2.6 Sunburst; na primeira comparação, fixa os prompts, as referências, o tamanho, a qualidade e o formato de saída, deixando a complexity no valor predefinido do modelo; altera apenas a qualidade ou a complexity, uma de cada vez; implementa por workflow, em batches, e acompanha a latência, as falhas, as repetições e o custo aceite por imagem. Os pedidos de edição devem omitir o antigo input_fidelity; o GPT Image 2.6 não suporta reasoning.summary.

Responses API: lê em separado os exemplos do guia e as páginas dos modelos

O guia de geração de imagens continua a explicar as ferramentas de imagem conversacionais em vários turnos através da Responses API, com identificadores do 2.5 nos campos de modelo da ferramenta de imagem dos exemplos. Em contraste, as tabelas de Endpoints das páginas dos modelos GPT‑Image‑2.6 Flare e Sunburst marcam ambas v1/responses como Not supported, e marcam v1/images/generations e v1/images/edits como Supported. A secção do 2.6 sublinha também que complexity, markup, SVG e GIF são fornecidos “através da Image API”.

As migrações para produção devem, por isso, ligar por defeito o 2.6 às generations e às edições da Image API, e não assumir que uma configuração de ferramenta da Responses da era do 2.5 pode simplesmente trocar para um ID do 2.6. Se o negócio depender muito da edição conversacional em vários turnos, volta a verificar pela tabela de Endpoints da página do modelo, que é a referência, em vez de extrapolares a partir de parágrafos do guia que ainda exemplificam a Responses do 2.5. É uma diferença real na documentação, e não uma discussão verbal sobre “quem se enganou a escrever”; quem integra deve condicionar a configuração de produção à página do modelo.

Sugestões de aceitação da migração

Divide a aceitação em três camadas. Capacidade: em corpora do negócio, verifica se o GIF/SVG/markup/complexity encurtam realmente a iteração ou reduzem edições erradas. Qualidade: compara os níveis correspondentes do 2.5 e do 2.6 com os mesmos prompts quanto a texto, identidade, geometria do produto e canais alfa. Integração: confirma a verificação da organização, o safety_identifier, o tratamento de erros (não repitas às cegas os bloqueios de moderação) e que as configurações não têm ligações à Responses não suportadas. Quanto aos preços, os preços unitários dos níveis do 2.6 verificados aqui coincidem; não assumas que “o nível mais rápido é mais barato”.

Na prática, atenção às mudanças de hábitos com os parâmetros. Se um workflow do 2.5 nunca definiu a complexity explicitamente, continuar a omiti-la depois de passar para o 2.6 leva ao valor predefinido high, o que pode alongar a latência das edições e acrescentar alterações indesejadas; o conselho oficial para a maioria das edições é, pelo contrário, definir low explicitamente. GIF e SVG existem apenas nas generations: os pipelines de edição que assumem que “qualquer formato pode ir e voltar” vão esbarrar numa parede no 2.6. O markup abrange o 2.5 e o 2.6 suportados, mas é mutuamente exclusivo com mask e prompt_rewriter; os scripts de migração precisam de verificações de exclusão mútua dos campos. O guia de prompting lembra ainda: omite input_fidelity nos pedidos de edição; o 2.6 não suporta reasoning.summary. São armadilhas comuns que compilam, mas falham ou desviam em tempo de execução.

Os testes A/B devem fixar o tamanho, a qualidade e o formato de saída, mover de cada vez apenas o ID do modelo ou a complexity, e guardar amostras intermédias. Se o negócio usar em conjunto o Images 2.6 do lado do produto ChatGPT e a API, faz a contabilidade em separado: nome do produto ≠ ID do modelo, e a quota/verificação não se sincronizam automaticamente. Escala com validação em pouco tráfego da taxa de falha e do custo aceite por imagem antes de alargares o encaminhamento por defeito; mantém uma janela de reversão para o 2.5 até as curvas de latência e de qualidade estabilizarem nos corpora do negócio.

Em resumo: as diferenças do 2.6 face ao 2.5 que se podem afirmar são a velocidade e um posicionamento mais forte em dois níveis, além da superfície de controlo de complexity, GIF, SVG e markup. O sucesso da migração depende de comparações nas mesmas condições, como indica o guia de prompting, e de encarar o facto documental de que “o guia ainda mostra a Responses do 2.5, enquanto as páginas dos modelos marcam a Responses do 2.6 como não suportada”, tratando depois a página do modelo como a autoridade para a produção.