O Images 2.6 introduz (e documenta de forma sistemática) dois controlos independentes na API: quality e complexity. Segundo o anúncio do produto, a qualidade da imagem controla o detalhe visual e a fidelidade, enquanto a complexity orienta “quanto planeamento entra na cena”. A OpenAI recomenda explicitamente: usa complexity baixa na maioria das tarefas de edição, para edições mais rápidas, combinando-a com o nível de qualidade de que o workflow precisa. O Changelog (2026-11-04) inclui também a complexity ajustável entre os destaques do lançamento do 2.6.

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

Confundir os dois é tratar “desenhar com mais finura” e “pensar mais” como um único botão. As definições oficiais vão no sentido contrário: a primeira rege a fidelidade da renderização; a segunda rege a profundidade do planeamento antes da renderização. Se mantiveres o velho hábito de que “omitir um parâmetro significa o máximo”, a complexity fica em silêncio no valor predefinido high, o que pode tornar as edições mais lentas e introduzir alterações indesejadas.

Valores, predefinições e custo

Segundo o guia de geração de imagens e o guia de prompting de imagens:

Ajustar a complexity não tem uma linha de faturação à parte. Uma complexity mais alta pode acrescentar latência e alterações adicionais indesejadas, por isso a documentação recomenda comparar os resultados na tarefa concreta em vez de usar sempre o máximo. A página do produto acrescenta: as cenas com muitos elementos ou restrições podem experimentar complexity medium ou high; as edições rápidas ficam melhor com definições mais baixas. Uma complexity mais baixa serve para alterações focadas, como trocar um fundo ou uma placa de rua; uma complexity mais alta ajuda em texto denso, composições complexas e relações entre objetos.

Quando o Flare corre com quality=low, a OpenAI diz que a geração pode ficar concluída em cerca de seis segundos; o Sunburst com qualidade medium/high está posicionado para mais detalhe e maior consistência nas edições. São efeitos combinados do nível do modelo e do nível de qualidade, não podem ser atribuídos só à complexity, e não deves afirmar que “um nível é sempre mais rápido” sem fazer a comparação.

Como fazer testes A/B

O guia de prompting dá uma disciplina de ajuste clara: altera uma definição de cada vez. Fixa a quality ao comparar a complexity; se a composição já estiver certa mas o texto pequeno for difícil de ler, compara valores de quality diferentes com a mesma complexity. A documentação usa o mesmo prompt de futebol em recorte de papel, com size="1024x1536" e quality="medium" fixos, para mostrar as diferenças do Sunburst entre complexity low/medium/high no troféu, na colocação do cartaz “CHAMPIONS” e no detalhe das camisolas: com complexity baixa aparece uma coroa no troféu e uma faixa grande à frente da equipa; com a média acrescentam-se louros e um emblema; com a alta, o cartaz passa para as bancadas e o primeiro plano fica para os jogadores e as pregas das camisolas. O exemplo mostra que, quando o prompt deixa a composição, o texto e o estilo pouco especificados, aumentar a complexity altera de forma significativa as decisões de composição; quando a composição, o texto e o estilo já estão fixados no prompt, uma complexity mais alta pode quase não mostrar diferença.

Nas edições dirigidas, o conselho oficial é começar em low e verificar se o detalhe circundante se mantém intacto. O anúncio do produto e o guia de geração concordam: alterações focadas, como trocas de fundo ou edições de placas de rua, adequam-se a complexity mais baixa; texto denso, composições complexas e relações entre objetos são onde medium/high vale mais a pena experimentar. Nas edições com markup, a complexity baixa costuma alinhar-se com a restrição de prompt “altera só o objeto circulado” e ajuda a suprimir desvios fora do círculo.

Combinações práticas (ainda dentro do que a documentação permite inferir)

Trata o “rascunho rápido” como: Flare + quality=low (ou medium) + complexity definida explicitamente como low nas edições (porque, se for omitida, assume high e pode até ser mais lento). Trata o “asset final” como: depois de escolheres Flare ou Sunburst, aumenta a quality e faz um teste A/B à parte para decidir se aumentas a complexity; não assumas que a qualidade max tem de ser combinada com complexity high. Ao migrar workflows existentes do 2.5, o guia de prompting sugere manter inalterados os prompts, as referências, o tamanho, a qualidade e o formato de saída na primeira comparação, deixar a complexity no valor predefinido do modelo e só ajustar depois da aceitação; acompanha o tempo de resposta, as falhas/repetições e o custo aceite por imagem antes de escalar.

Tem também em conta os limites gerais: os prompts complexos podem demorar até cerca de dois minutos; a renderização de texto e o controlo da composição continuam a ter limites. Os parâmetros apenas trocam fidelidade, planeamento e latência dentro do envelope de capacidades do modelo; não eliminam a moderação de conteúdo nem os limites de simulação ao nível da física. Usa xhigh e max só quando melhorarem claramente uma qualidade por satisfazer e o orçamento de latência o permitir; a documentação não garante que os níveis mais altos sejam melhores para todos os prompts.

Em resumo: quality responde a “com que finura desenhar”, complexity responde a “com que profundidade planear”. O Images 2.6 separa-os e, na orientação oficial, encaminha a maioria dos cenários de edição para complexity baixa; quem mantiver o hábito de “omitir = máximo” fica antes com a profundidade de planeamento alta por predefinição. Define os parâmetros explicitamente e faz comparações de uma única variável, como a documentação descreve.