GPT-Image-2.6 vs GPT-Image-2.5: a troca é uma única string, a fatura não.

Migrar do GPT-Image-2.5 para o GPT-Image-2.6 é, no nível da API, a atualização menos dramática que a OpenAI lançou o ano todo. Os mesmos dois endpoints, a mesma tabela de preços, a mesma divisão entre Flare e Sunburst. A string do modelo muda e nada mais precisa mudar. É aí que está a armadilha também. O GPT-Image-2.6 adiciona um parâmetro que o GPT-Image-2.5 nunca teve — um controle de complexidade — e omiti-lo não o desativa. Ele vem definido como alto por padrão. Um pipeline que troca a string e entra em produção não está comprando a mesma quantidade de trabalho pelo mesmo dinheiro; está comprando mais trabalho, e é por isso que o primeiro relatório de custos após uma migração pode mudar mesmo que as tarifas publicadas não tenham mudado.

Ambos os modelos passaram à disponibilidade geral nos mesmos termos comerciais, e é isso que torna esta comparação incomum. Não há discussão sobre preços a ter. A discussão é inteiramente sobre onde o novo trabalho é investido e se o seu tráfego tem o perfil que faz com que ele se beneficie disso.

A superfície da API é mesmo um substituto direto — mas com uma lacuna.

A OpenAI lançou o GPT-Image-2.6 em 4 de novembro de 2026 como dois modelos de API, em vez de um, herdando a estrutura que estabeleceu com o 2.5. O nível voltado ao detalhe e à consistência é o GPT-Image-2.6 Sunburst; o nível de velocidade é o GPT-Image-2.6 Flare. Seus antecessores, GPT-Image-2.5 Sunburst e GPT-Image-2.5 Flare, mantêm os mesmos nomes e a mesma relação entre si.

• Strings de modelo — gpt-image-2.6-flare e gpt-image-2.6-sunburst substituem gpt-image-2.5-flare e gpt-image-2.5-sunburst, mesma lógica de nomenclatura, um para latência e outro para detalhe.

• Endpoints — /v1/images/generations e /v1/images/edits, inalterados. Nenhum novo endpoint para integrar.

• Tarifas — US$ 5 por milhão de tokens de entrada de texto, US$ 8 por milhão de tokens de entrada de imagem, US$ 30 por milhão de tokens de saída de imagem, com entrada em cache a US$ 1,25 e US$ 2,00. Idêntico byte a byte ao 2.5.

• Níveis de qualidade — baixo, médio, alto, xhigh, máximo e automático. Mesma escala.

• Tamanhos recomendados — 1024×1024, 1536×1024 e 1024×1536 continuam a liderar a documentação, com dimensões personalizadas aceitas em múltiplos de 16 e proporções de 1:3 a 3:1.

• A lacuna — o 2.6 não está disponível pela Batch API. Se o seu gasto com imagens depende de um job noturno pela metade do preço, esse job ainda não sai do lugar.

Essa última linha é a que realmente quebra algo. Tudo acima dela é uma substituição de string e uma execução de regressão. A lacuna no processamento em lote é um bloqueio arquitetural exatamente para as cargas de trabalho — catálogos em massa, backfills noturnos, geração de A/B em larga escala — em que um desconto de 50% é a razão pela qual a carga de trabalho existe.

O seletor de complexidade é o verdadeiro recurso, e seu valor padrão é a surpresa.

A complexidade é um novo eixo que fica ao lado da qualidade, e não dentro dela, e a distinção importa mais do que parece. A qualidade controla a renderização: quantos tokens de saída entram na imagem. A complexidade controla o planejamento: quanto raciocínio o modelo faz antes de começar a renderizar. Você pode pedir uma imagem de baixa qualidade de uma cena complicada, ou uma imagem de alta qualidade de uma cena simples, e no 2.6 essas são solicitações genuinamente separadas.

A documentação é explícita: omitir o parâmetro faz com que ele assuma o valor alto por padrão. Assim, quem migra uma requisição 2.5 apenas alterando o nome do modelo e nada mais está, silenciosamente, optando pelo orçamento máximo de planejamento a cada chamada. Isso não é um bug — é o padrão sensato para um modelo cujo principal atrativo é pensar mais —, mas significa que o primeiro mês de tráfego do 2.6 não é uma comparação equivalente com o último mês de tráfego do 2.5.

Há pelo menos um dado público apontando na mesma direção. Um teste prático com três imagens publicado em 4 de novembro relatou US$ 0,1245 para a saída do 2.6, contra US$ 0,0446 para as mesmas imagens estáticas no 2.5 — cerca do triplo, em uma tabela de preços que não mudou. Três imagens não são um benchmark e não devem ser citadas como tal; a amostra é pequena demais para estabelecer um multiplicador. O que esse teste faz é demonstrar o mecanismo, e o mecanismo está documentado: mais tokens de planejamento por solicitação, ativados por padrão, cobrados a US$ 30 por milhão.

Se você for seguir apenas um passo operacional deste artigo, siga este. Defina a complexidade explicitamente — médio é um primeiro palpite razoável para corresponder ao comportamento da era 2.5 — e então meça os tokens de saída por solicitação antes e depois. Não meça dólares por solicitação. Dólares por solicitação dirão que a tabela de preços não mudou, o que você já sabia. Tokens por solicitação dirão se o modelo está fazendo mais trabalho do que você pediu.

Onde o alegado ganho de velocidade de 50% realmente se concretiza

A OpenAI descreve o GPT-Image-2.6 como cerca de 50% mais rápido no geral, mas os números por nível são bem mais interessantes do que a manchete — e são números do próprio fornecedor, não medidos de forma independente. Relata-se que o Flare é cerca de 2,6× seu antecessor, com renderizações de baixa qualidade sendo concluídas em apenas seis segundos. Relata-se que o Sunburst é cerca de 1,15×.

Esses dois números descrevem dois upgrades completamente diferentes. Se o seu pipeline executa o Flare para iteração — exploração de miniaturas, ajuste de prompts, qualquer coisa em que uma pessoa esteja esperando o resultado —, o 2.6 é uma mudança de patamar, e a migração se paga só em atenção. Se o seu pipeline executa o Sunburst para a qualidade do resultado final, uma melhoria de 15% na latência está dentro da faixa de ruído entre execuções na maioria das configurações de hospedagem, e velocidade não é motivo para migrar de forma alguma.

Vale sinalizar com honestidade: o mesmo pequeno teste prático que relatou a inflação de tokens também relatou que o 2.6 foi mais lento que o 2.5 em suas três imagens, o que contradiz a afirmação do fornecedor. Com n=3, isso é ruído, não uma refutação. Mas é um lembrete de que "50% mais rápido" é um agregado de apresentação de lançamento entre níveis de qualidade, e um pipeline real vê um único nível com uma única configuração de qualidade.

Ninguém marcou 2,6 ainda, e 2,5 continua em primeiro.

Esta é a parte da comparação que a maior parte da cobertura está deixando de lado. A Artificial Analysis, que opera seus painéis AA-Image-T2I v2.1 e de edição, não tinha nenhuma linha para o GPT-Image-2.6 quando consultada em 5 de novembro de 2026. Não uma pontuação baixa — nenhuma linha.

O que esses painéis mostram é que o modelo que está sendo substituído ainda está vencendo neles:

• Texto para imagem — GPT-Image-2.5 Sunburst (max) 1.224 Elo de 13.153 votos, primeiro. GPT-Image-2.5 Flare (max) 1.207 de 12.498, segundo. GPT Image 2 (high) 1.188, terceiro.

Edição de imagens — GPT-Image-2.5 Sunburst (max) 1.200 de 18.370 votos, primeiro. GPT-Image-2.5 Flare (max) 1.183 de 19.259, terceiro, atrás de MAI-Image-2.7-Preview, com 1.197.

O material de lançamento da OpenAI cita o Design Arena para um primeiro lugar do 2.6 Sunburst. É uma afirmação real em um ranking real, mas é um conjunto de avaliadores diferente em uma escala diferente, e um fornecedor escolher o ranking que favorece seu lançamento não é evidência de nada que um comprador possa usar. A pontuação comparável, de terceiros e baseada em votos, para o 2.6 ainda não existe. Até que exista, a posição defensável é que o 2.5 é o modelo de imagem com maior pontuação independente nos dois principais rankings e que o 2.6 não foi comprovado — melhor nas formas específicas que a OpenAI diz que ele é melhor, e não medido em todos os outros aspectos.

Uma migração que cabe em uma tarde

A troca é barata o suficiente para que a abordagem sensata não seja uma migração big-bang, mas uma migração criteriosa, executada com os seus próprios prompts, e não com o conjunto de prompts de benchmark de outra pessoa.

Comece fixando a complexidade em um valor que você escolheu, para que a mudança seja uma mudança que você fez, e não uma que chegou por padrão. Depois, execute novamente algumas centenas de prompts reais dos seus logs de produção — não os prompts limpos dos seus fixtures de teste, mas os bagunçados, com erros de digitação e proporções de aspecto estranhas. Compare dois números: tokens de saída por imagem aceita e imagens aceitas por cem tentativas. O segundo é onde uma melhoria de consistência apareceria, e é o número que de fato determina se a atualização economiza dinheiro, porque uma imagem descartada custa o orçamento inteiro de tokens e não retorna nada.

Mantenha um caminho alternativo para a versão 2.5 para o trabalho em lote, já que a 2.6 ainda não consegue atender a essa demanda. E trate qualquer tráfego do Sunburst como uma questão de qualidade, e não de velocidade — se a taxa de aceitação não mudar, você comprou uma melhoria de 15% na latência e uma conta de planejamento maior.

Quando permanecer na versão 2.5 é a resposta certa

Três casos são claros o suficiente para nomear. As cargas de trabalho em lote devem permanecer, porque a versão 2.6 não está na Batch API e a 2.5 está. Os pipelines de qualidade Sunburst devem permanecer, a menos que o teste de taxa de aceitação diga o contrário, porque um ganho de velocidade de 1,15× não compensa uma mudança no modelo de custos. E qualquer pessoa cuja taxa de aceitação atual já seja aceitável deve permanecer, porque os novos recursos — exportação SVG, GIF animado, edição guiada por marcação — são recursos adicionais, não melhorias de qualidade, e você só precisa deles se tiver um entregável que os exija.

A atualização é genuína. Ela está apenas concentrada na latência do Flare e em novos formatos de saída, e estes são mais restritos do que "um novo modelo" sugere.

Disponibilidade e a forma incômoda de uma migração dividida

A OrcaRouter disponibiliza hoje o GPT-Image-2.5 Flare e o GPT-Image-2.5 Sunburst ao preço de tabela, com 0% de markup, pelo que a tarifa do fornecedor é a tarifa que paga, sem qualquer margem acrescentada. O GPT-Image-2.6 não consta do catálogo a 5 de novembro de 2026 — um dia após o lançamento —, o que faz com que o problema prático imediato seja de encaminhamento e não de modelação: durante a avaliação comparativa, o tráfego do 2.5 corre numa única chave com failover automático, enquanto o tráfego do 2.6 segue diretamente para a OpenAI ao abrigo de um segundo contrato e de uma segunda fatura.

Vale a pena planejar em torno dessa divisão, em vez de descobri-la. Verifique o catálogo antes de comprometer um caminho de produção com o 2.6, porque paridade no dia do lançamento não é algo que qualquer roteador possa prometer para um modelo de vinte e quatro horas. Quando ele chegar, a regra de repasse significa que a tarifa do fornecedor é o que você paga no mesmo dia — uma mudança de preço do lado da OpenAI chegaria sem uma renegociação do nosso — mas, até lá, a leitura honesta da situação é que o 2.5 é roteável e o 2.6 não é.

O que é mais um argumento a favor da migração do tamanho de uma tarde em vez da do tamanho de um fim de semana. Passe a 2.5 pelo roteador, mantenha sua linha de base de custos estável e adicione a 2.6 atrás de uma flag depois de medir o que o padrão de complexidade faz com suas contagens de tokens. O modelo não vai a lugar nenhum, e o endpoint de lote chegará antes do seu próximo ciclo de planejamento trimestral.