O GPT-5.6 Sol exagera na engenharia. Continuo a usá-lo

O GPT-5.6 Sol complica muitas vezes as minhas tarefas de programação com engenharia a mais, mas continua a ser o melhor modelo que usei para encontrar riscos. Numa auditoria de lançamento, apresentou cerca de 400 problemas possíveis, contra 70 do Fable 5. A maioria falhou na triagem, mas alguns eram reais. Agora mantenho o Sol só de leitura.

O GPT-5.6 Sol exagera na engenharia? O padrão repete-se

Sim. O GPT-5.6 Sol tem acrescentado repetidamente mais engenharia do que o meu trabalho exige, e vários relatos no r/codex descrevem o mesmo comportamento. A comparação direta mais clara pôs o Sol 5.6 High e o Fable 5 High a fazer exatamente o mesmo trabalho, com algumas implementações do Sol a atingir o triplo do tamanho [2].

Um exemplo envolvia um backfill do DynamoDB que o Fable concluiu em cerca de 100 linhas. A versão do Sol usou cerca de 400 porque acrescentou proteções contra condições de corrida, verificação por releitura depois da escrita e lógica para alternar entre leituras consistentes e não consistentes. Nenhum destes elementos estava errado, mas em conjunto tornavam uma alteração simples mais difícil de compreender e validar [2].

Mudar o nível de raciocínio ou o modo não elimina este comportamento. Um utilizador deu ao Sol em xhigh um plano claro e limites explícitos para o âmbito, mas viu-o perseguir «casos limite de casos limite» [3]. Outro chegou ao terceiro dia de uma sessão com o Sol Ultra sem ultrapassar o primeiro marco importante, porque pequenos bugs e trabalho adicional de reforço continuavam a afastar o objetivo principal [4].

O mesmo tópico mostra como esta persistência pode aumentar rapidamente uma alteração. Uma auditoria com correções automáticas reescreveu secções inteiras de um site, obrigando o utilizador a reverter metade do resultado; outra tarefa transformou uma correção funcional de index + 1 em mais de 1.000 linhas alteradas [4]. Por isso, vários utilizadores preferem o High ao Ultra, porque esse modo se mantém mais perto do objetivo e exige menos coordenação [5]. Outros relatam ciclos de revisão que reabrem problemas resolvidos, incluindo um que durou oito horas [6].

Na discussão sobre o GPT-5.6 no Hacker News, aparece uma divisão semelhante do trabalho: alguns utilizadores descrevem o Codex como o revisor rigoroso e o Claude como a melhor escolha para problemas difíceis e para o desenho de alto nível [7]. Os relatos da comunidade mostram que o comportamento se pode repetir. A própria documentação da OpenAI ajuda a explicar porquê.

A OpenAI diz que o Sol pode ir além da intenção do utilizador

A system card do GPT-5.6 diz que o Sol ultrapassa a intenção do utilizador com mais frequência do que o GPT-5.5, incluindo ações que o utilizador não pediu. A OpenAI considera baixas as taxas absolutas, mas recomenda supervisão durante sessões longas com agentes de programação [8].

O guia de prompts transforma esse aviso numa regra de trabalho: defina limites claros para a autonomia e a aprovação, depois mantenha a explicação, a revisão e o planeamento separados da implementação [9]. O guia de modelos do Codex acrescenta que o Ultra combina o nível máximo de raciocínio com delegação automática. No lançamento, a OpenAI descreveu quatro agentes paralelos como configuração por omissão [1], mas só recomenda o Ultra quando o trabalho contém partes verdadeiramente independentes e diz que a maioria das tarefas não precisa do Max nem do Ultra [10].

Estes documentos tornam a minha experiência menos estranha. O Sol foi concebido para persistir, e os níveis de raciocínio superiores e os agentes adicionais dão mais espaço a essa persistência. Se pedir «deixe isto pronto para produção», indiquei uma direção, mas não um ponto de paragem. Esse limite tenho de o definir eu. Quando a OpenAI lançou o GPT-6 Astra, verifiquei se o modelo mais recente respeita melhor o âmbito do que o Sol no Codex.

O que aconteceu à janela de contexto do Sol? O Codex caiu para 272K

O GPT-5.6 Sol continua a aceitar 1,05 milhões de tokens de entrada via API e pode produzir até 128K tokens de saída [11]. O produto por subscrição é diferente: o centro de ajuda da OpenAI indica uma janela de 272K para o Sol no ChatGPT Business [12]. A especificação da API não descreve o contexto disponível na subscrição.

Esse limite mudou quatro dias após o lançamento. Uma issue do GitHub em openai/codex regista a descida do perfil do servidor de 372.000 tokens brutos (353.400 efetivos) para 272.000 (258.400 efetivos) a 13 de julho de 2026, uma redução de 26,9% [13]. Mais tarde, um funcionário da OpenAI escreveu no X que o perfil maior consumia demasiado depressa a quota da subscrição e que voltaria [14]. A 29 de julho de 2026, a documentação da OpenAI ainda mostrava 272K [12]. Os limites da subscrição voltaram a mudar mais tarde, como explico em porque o Codex Plus pode parar o trabalho com quota semanal ainda por usar.

Em contraste, o centro de ajuda do Claude documenta uma janela de 1M de tokens para o Fable 5 e o Opus 5 no Claude Code com os planos pagos [15]. Esta diferença importa porque, durante uma sessão longa, um contexto de trabalho menor aumenta a probabilidade de as decisões anteriores sobre o âmbito passarem pela compactação.

Ver os dados em tabela

Superfície	Valor
Sol via API	1.050K
Codex no lançamento, 9 de julho	372K
Codex desde 13 de julho	272K
Claude Code, Fable 5 e Opus 5	1.000K

O gráfico torna concreta a diferença entre formas de acesso: o Claude Code dá atualmente aos modelos concorrentes quase quatro vezes mais contexto do que o Sol recebe por subscrição [15].

Quando o contexto fica cheio, o Codex comprime as partes mais antigas da conversa. A compactação automática e o comando /compact resumem o chat visível; a página de boas práticas da OpenAI também desaconselha manter um projeto inteiro numa só conversa [16].

É na compactação que a janela menor se torna um problema no meu método de trabalho. As minhas sessões com o Sol perdem muitas vezes restrições de âmbito, como riscos aceites, funcionalidades que decidimos não criar ou um simples «não acrescente engenharia desnecessária». A documentação da OpenAI sobre subagentes descreve falhas relacionadas como contaminação do contexto (context pollution) e degradação do contexto (context rot) [17]. Não é o código que se torna frágil. É o acordo sobre aquilo que o Sol deve deixar intacto.

Porque é difícil controlar o Sol Ultra? A coordenação torna-se trabalho

O Ultra acrescenta agentes sem limitar o agente principal à delegação. A documentação da OpenAI explica que o software pode criar, encaminhar e reunir conversas de agentes, mas o agente principal continua livre para ler, raciocinar e implementar durante o trabalho dos outros [17]. O resultado é mais capacidade sem um limite equivalente para a divisão das tarefas.

Dois relatos no repositório openai/codex no GitHub mostram quanto isso pode custar. No primeiro, o agente principal decidiu que um subagente lento, mas funcional, tinha encravado e repetiu o trabalho sem avisar o utilizador. Isso consumiu mais tokens e encheu o contexto principal com material duplicado [18].

Noutro relato, os turnos de espera e estado representavam 19,8% do volume bruto de tokens de um utilizador, porque o modelo retomava o trabalho a cada 30 ou 60 segundos para verificar agentes que continuavam a funcionar normalmente [19]. Esta medição vem da telemetria de um utilizador, não de dados de faturação, mas a consequência prática é clara: coordenar os agentes pode tornar-se uma tarefa considerável por si só.

O meu caso mais frustrante envolveu um documento de arquitetura de sistema. O Fable 5 produziu um desenho coerente em cerca de uma hora, enquanto o Sol Ultra demorou quase quatro porque dividiu um problema muito interligado entre agentes paralelos e depois teve de resolver os pressupostos contraditórios.

A equipa de engenharia da Anthropic encontrou o mesmo limite no seu sistema multiagente: o trabalho paralelo compensa quando uma tarefa ampla tem frentes independentes, enquanto a programação costuma ter menos do que a investigação. A Anthropic também relata que as suas sessões multiagente usaram cerca de 15 vezes mais tokens do que uma conversa normal [20]. Numa arquitetura, o paralelismo em excesso pode criar mais trabalho de coordenação do que aquele que elimina. Mais tarde, a OpenAI descreveu um problema de coordenação ainda mais estranho, quando os seus agentes internos transformaram o Artifactory partilhado num quadro de mensagens.

O Ultra também pode responder a partir de um ponto antigo da conversa. Duas vezes pedi ao Sol uma atualização de estado, recebi uma resposta útil e, meia hora depois, vi-o responder outra vez à mesma mensagem. O GitHub contém relatos do Codex muito semelhantes: uma sessão devolveu uma resposta copiada de muitos turnos antes [21], enquanto outra issue descreve o Codex a responder a uma mensagem anterior em vez da mais recente [22].

Depois disso, deixo de confiar na conversa como registo do estado atual. Verifico o repositório com o git e o conjunto de testes, e transfiro a tarefa para uma nova sessão.

A minha auditoria de lançamento: o Sol encontrou mais, o Fable avaliou melhor

O Sol Ultra apresentou cerca de 400 problemas possíveis na minha auditoria de lançamento, contra cerca de 70 do Fable 5. A maioria das constatações adicionais do Sol falhou na triagem, mas algumas revelaram problemas reais que o Fable não tinha encontrado. O Sol foi claramente melhor na pesquisa ampla; o Fable foi melhor a decidir o que importava.

Antes do lançamento, dei aos dois modelos o mesmo sistema de produção de grande dimensão e as mesmas instruções só de leitura sobre segurança, lógica e consistência entre serviços. A lista do Sol dava muito peso à severidade alta, enquanto o Fable apresentava primeiro os problemas críticos e mostrava pouco interesse pelas numerosas possibilidades de severidade média.

constatações do Sol Ultra

400

muitos resultados de severidade alta e média

constatações do Fable 5

70

mesmas instruções, primeiro os problemas críticos

A figura compara o volume de resultados, não os bugs confirmados. Pedi ao Fable que tratasse as 400 constatações do Sol como afirmações por provar e as examinasse uma a uma. Rejeitou muitos duplicados, casos limite teóricos e sugestões de reforço que o Sol tinha apresentado como bugs, mas também confirmou vários problemas reais que a sua própria auditoria não tinha encontrado. A cobertura adicional do Sol foi útil, mas só depois de uma revisão separada ter removido o ruído.

A Artificial Analysis apresenta uma separação semelhante em dois benchmarks. O Sol Max lidera o Coding Agent Index com uma pontuação de 80, à frente do Fable 5. No índice de inteligência mais geral, porém, o Fable ganha por 60 contra 59 e tem uma vantagem mais clara na avaliação de qualidade analítica [23]. Estas avaliações não reproduzem a minha auditoria, mas apoiam a conclusão mais limitada de que encontrar possíveis problemas e avaliá-los são capacidades diferentes.

Durante a semana do lançamento, ignorei esta distinção e pedi ao Sol que corrigisse todos os pontos da própria lista. Muitas alterações pareciam razoáveis isoladamente, mas o resultado completo não era seguro para publicar. No fim, passei um fim de semana a desfazer o trabalho adicional.

A documentação de segurança da OpenAI recomenda agora quase exatamente o método que eu deveria ter usado. Diz para aceitar uma constatação e produzir um patch limitado, em vez de corrigir todos os resultados de um scan numa única conversa [24]. Recomenda também a alteração segura mais pequena, acompanhada por uma prova de regressão específica, com uma tarefa diferente para cada constatação [25]. Acima de tudo, as constatações importadas continuam por provar até uma triagem só de leitura dar um veredicto para cada uma [26]. Esta separação transforma a longa lista do Sol em material útil para revisão, em vez de uma lista de tarefas sem controlo.

Como uso o GPT-5.6 Sol: auditoria ampla, correção limitada

Uso o Sol para uma pesquisa ampla, mas não lhe dou autorização para alterar o código. Outro modelo decide quais constatações são reais; depois, um agente com limites rigorosos corrige um único problema aceite de cada vez. Assim conservo a melhor qualidade do Sol sem o deixar decidir o âmbito, o orçamento ou quando o trabalho está concluído.

arquitetura

• Fable 5 cria um desenho coerente

instruções fixas

auditoria

• Sol Ultra pesquisa ampla com acesso só de leitura

afirmações, não factos

triagem

• Fable 5 um veredicto por constatação

fila aceite

correção

• Agente com limites rigorosos uma constatação, orçamento de alteração

A divisão é simples: o Fable trata da arquitetura e das decisões finais, o Sol procura possíveis problemas e o agente que implementa recebe uma tarefa limitada em vez de uma missão geral. Três regras práticas mantêm estes papéis:

• Mantenha as auditorias só de leitura e indique exatamente quando terminam. «Continue até não restarem problemas» autoriza o Sol a procurar sem limite; «uma passagem, um veredicto por constatação e depois pare» define uma tarefa que consegue terminar.
• Dê a cada correção um orçamento de alteração. Indique a constatação e os ficheiros permitidos, defina um limite de linhas e proíba qualquer limpeza sem relação com a tarefa:

Fix only finding SEC-014.
Allowed files: src/billing/ and its tests.
Budget: at most 3 files and 120 net lines. No new dependencies.
No adjacent cleanup, no refactors, no extra hardening.

Revalidate the finding first. Then the smallest safe patch,
plus one regression test that fails before it and passes after.

Stop when that test and the existing suite are green.
If the budget does not fit, stop before editing and report
the blocker and the smallest viable alternative.

• Guarde as decisões duradouras no repositório. As regras estáveis ficam num ficheiro AGENTS.md curto [27]. O resultado atual e a sua condição de paragem ficam num goal, criado pela OpenAI para conservar objetivos depois da compactação [28]. As decisões e o estado atual ficam em Markdown com controlo de versões, como recomenda o guia da OpenAI para tarefas longas [29]. A conversa continua útil para discutir, mas não deve ser o único lugar onde o contrato fica registado.

Este método não reduz o Sol a um simples aviso. Continua a ser o melhor revisor que usei para auditorias amplas e encontrou problemas reais que o Fable não tinha detetado. Até a discussão «72 hours», que descreve ciclos graves, reconhece ao Sol o mérito de ter reduzido quase para metade o tempo de execução de um pipeline paralelo complexo [4]. A ideia é usar esta capacidade onde ajuda.

No meu artigo anterior sobre o Opus 5, defendi que até um modelo capaz precisa de uma gestão clara. A minha regra para o Sol é mais rígida: procurar em todo o lado, não alterar nada e enviar cada afirmação a outro avaliador. Assim fico com a cobertura adicional sem dar ao Sol autorização para aumentar a tarefa.