ChatGPT Images 2.5 chega à API com dois modelos e foco em edição precisa

A OpenAI anunciou o ChatGPT Images 2.5, a nova geração dos seus modelos de geração de imagem, e a novidade que importa para quem constrói não está na interface do ChatGPT, e sim na API. Como registrou Simon Willison em seu blog (simonwillison.net), a família ganhou dois novos IDs de modelo: gpt-image-2.5-sunburst e gpt-image-2.5-flare. Para quem tem um SaaS gerando thumbnails, um pipeline de automação de conteúdo ou qualquer feature que dependa de imagem sob demanda, essa bifurcação é a parte que muda o código.

O próprio número que a OpenAI usa para justificar a escala impressiona: segundo o material citado por Willison, os modelos de imagem da empresa já foram usados para gerar "mais de 3 bilhões de imagens no ChatGPT Images e nos modelos GPT‑Image via API". Ou seja, não é um brinquedo de demo, é infraestrutura que já roda em volume de produção.

Sunburst x Flare: escolher o modelo virou decisão de arquitetura

Até aqui, integrar geração de imagem na OpenAI era escolher um modelo e mandar o prompt. Com a 2.5, a decisão passa a ter um eixo de trade-off explícito entre precisão de edição e velocidade/custo por imagem cotidiana. A própria documentação resume assim:

Choose Sunburst for workflows where editing precision matters most, and Flare for fast, high-quality everyday image generation.

OpenAI, via Simon Willison

A leitura de Willison é direta: Sunburst é o modelo mais forte, indicado para fluxos em que a precisão da edição é o que mais pesa (retocar, ajustar, respeitar composição). Flare é o cavalo de trabalho para geração de alto volume, onde você quer qualidade boa e resposta rápida sem pagar o preço do modelo mais caro.

Na prática, isso significa que uma decisão que antes era binária (usar ou não a API de imagem) agora tem um degrau intermediário de engenharia:

Vale o aviso: a fonte não traz a tabela de preços nem números de latência medidos dos dois modelos. Então o "mais barato" e o "mais rápido" aqui são a promessa de posicionamento da OpenAI, não um benchmark. Antes de trocar o modelo do seu pipeline, meça o custo por imagem no seu volume real, os dois IDs precisam entrar num teste A/B com o seu próprio prompt e a sua própria referência.

As três melhorias que a OpenAI destaca

Segundo o release citado, a 2.5 melhora em três frentes concretas:

1. Aderência a instruções em múltiplos turnos — a capacidade de manter contexto quando você refina a imagem em várias mensagens ("agora deixe o fundo mais escuro", "aumente o contraste do texto"). Isso é o que mais dói em automação: um modelo que "esquece" a instrução anterior obriga você a reescrever o prompt inteiro a cada iteração.
2. Resposta mais rápida — relevante direto no custo de infraestrutura e na experiência de qualquer feature síncrona, onde o usuário espera a imagem carregar.
3. Preservação de sujeitos em fotos de referência — nas palavras do material, o modelo "is better at preserving the subjects in your reference photos". Esse é o ponto que destrava casos de uso sérios: editar a foto de um produto sem deformá-lo, manter o rosto de um personagem consistente entre gerações, colocar um elemento novo numa cena existente sem quebrar o resto.

O caso concreto: imagens de referência via CLI

Willison fez o que costuma fazer: atualizou sua ferramenta de linha de comando openai_image.py para aceitar uma ou mais imagens de referência e testou na hora. O comando que ele publicou dá o exemplo mais tangível de como isso fica no terminal, usando uv para rodar o script direto da URL:

uv run https://tools.simonwillison.net/python/openai_image.py \
  'add a raccoon scientist studying the chart thoughtfully' \
  -i https://static.simonwillison.net/static/2026/openai-agent-usage.webp \
  -m gpt-image-2.5-sunburst

O que está acontecendo aí: a flag -i passa a imagem de referência (um gráfico), o prompt pede para adicionar um guaxinim cientista estudando o gráfico, e -m seleciona o Sunburst. O modelo recebe a imagem original e a instrução de edição, e devolve a versão modificada preservando o gráfico. É exatamente o fluxo de "editar preservando o sujeito" que a OpenAI vende, testado num comando de uma linha.

Para o dev brasileiro, o detalhe do uv run apontando direto para uma URL é um padrão que vale copiar: dá para distribuir uma ferramenta de geração de imagem sem exigir pip install, venv ou clone de repositório. O usuário só precisa do uv e da variável de ambiente com a chave da OpenAI.

O que isso muda no seu pipeline

Se você já roda geração de imagem em produção, a chegada da 2.5 recoloca duas perguntas:

• Custo x qualidade agora tem dois pontos na curva. Se hoje você usa um único modelo para tudo, provavelmente está pagando caro em geração trivial ou entregando qualidade baixa em edição fina. Segmentar as chamadas entre Flare (volume) e Sunburst (edição crítica) é a otimização óbvia, e mensurável no seu billing.
• Referência confiável abre casos que antes eram frágeis. Consistência de personagem, retoque de produto e composição sobre imagem existente eram justamente onde os modelos de difusão escorregavam. Se a melhoria de preservação se confirmar no seu teste, dá para promover esses fluxos de "experimento" para "feature".

Onde não vale a pena migrar às cegas: qualquer pipeline que dependa de custo previsível não deve trocar de modelo sem antes rodar o próprio volume nos dois IDs e comparar a fatura. E se o seu caso é geração local ou offline (sem depender de API paga), a 2.5 não muda nada, ela é um serviço fechado da OpenAI, não um modelo aberto que você baixa e roda no seu hardware. Para esses cenários, o stack continua sendo modelos abertos rodando localmente.

O release é curto, mas o recado técnico é claro: a OpenAI transformou "gerar imagem" numa decisão com dois SKUs, e quem constrói precisa tratar a escolha do modelo como parte da arquitetura, não como default. O melhor teste ainda é o que Willison fez: pegar seu próprio prompt, sua própria imagem de referência, rodar nos dois modelos e medir.

Fonte: Simon Willison