O GPT-5.6 Sol encontra tudo. O problema é esse

O GPT-5.6 Sol prefere perseguir um risco a mais do que deixar escapar um. Esse único traço produziu, ao mesmo tempo, a auditoria mais completa que o meu código alguma vez recebeu e as correções com mais engenharia a mais que alguma vez tive de reverter. O modelo está bem. O que falha é a autoridade que lhe entregamos, e isso tem conserto.

A OpenAI lançou a família GPT-5.6 a 9 de julho de 2026, com o Sol no topo e o Ultra como modo multiagente [1]. Nos vinte dias desde então, tenho executado o Sol lado a lado com o Fable 5 e o Opus 5 da Claude nos mesmos repositórios, e não me livro de uma sensação incómoda: admiro este modelo, e não confio totalmente nele enquanto trabalha. Este artigo é a minha forma de verificar se o problema é meu ou é um padrão. É um padrão.

O Sol exagera mesmo na engenharia, ou sou só eu?

Não é só você. No r/codex aparece vezes sem conta a mesma medição: código correto, código a mais. O tópico mais claro compara o Sol 5.6 High com o Fable 5 High em tarefas idênticas e descreve implementações do Sol por vezes três vezes maiores [2].

O exemplo concreto desse tópico é um backfill de DynamoDB. O Fable resolveu-o em cerca de 100 linhas. O Sol produziu cerca de 400, acrescentando proteções contra race conditions, verificação por releitura depois da escrita e alternância entre leituras consistentes e não consistentes. O veredicto do autor não foi que o código estivesse errado. Foi que tanta exaustividade tornava a alteração mais difícil de entender e de validar [2].

O padrão sobrevive a mudanças de nível e de modo. Um utilizador descreve o Sol em xhigh a caçar “edge cases de edge cases”, apesar de um plano definido e de barreiras explícitas contra a deriva de âmbito [3]. No tópico intitulado “72 hours of Sol Ultra”, o modelo ainda não tinha passado o primeiro grande marco ao fim de três dias, porque bugs cada vez mais pequenos e tarefas de endurecimento saltavam constantemente para a frente do objetivo [4]. No mesmo tópico há um utilizador cuja auditoria com correção automática reescreveu secções inteiras do site, metade das quais teve de ser revertida, e outro cujo arranjo funcional de index + 1 acabou refatorizado numa alteração com mais de 1.000 linhas [4]. Vários utilizadores preferem simplesmente o High ao Ultra: mais concentrado, menos ruído de coordenação, melhor a segurar o objetivo principal [5]. Outros descrevem ciclos de implementação e revisão que reabrem durante horas problemas já resolvidos, um deles durante oito [6].

Entretanto, no Hacker News, a divisão de papéis já virou folclore: o Codex como revisor picuinhas, a Claude para os problemas difíceis e o design de alto nível [7].

A OpenAI escreveu ela própria a lista de queixas

A confirmação mais forte é oficial. A system card do GPT-5.6 reporta uma tendência maior do que a do GPT-5.5 para ir além da intenção do utilizador, incluindo executar ou tentar ações que ninguém pediu, e recomenda supervisão em sessões longas de agentes de código. As taxas absolutas, ressalva, continuam baixas [8]. Insistência treinada, documentada pelo próprio fabricante.

O guia de prompting transforma o mesmo traço em conselho: o GPT-5.6 é proativo e persistente, por isso defina limites explícitos de autonomia e de aprovação, e mantenha explicar, rever e planear rigorosamente separados de implementar [9]. O guia de modelos do Codex é igualmente direto sobre a escada de modos: o Ultra é raciocínio máximo mais delegação automática de tarefas, descrito no lançamento como quatro agentes paralelos por omissão [1], recomendado quando o trabalho se divide de facto em partes paralelas, e a maioria das tarefas não precisa nem de Max nem de Ultra [10].

Ponha os três documentos lado a lado e a forma do problema torna-se visível. Um modelo treinado para não deixar pedra sobre pedra, com mais orçamento de raciocínio, agentes extra e um objetivo aberto do género “deixa isto pronto para produção”, não tem nenhum ponto natural de paragem. Nada disto é um bug. Tudo isto é política de produto.

O que aconteceu à janela de contexto do Sol?

O modelo via API aceita 1,05 milhões de tokens e emite até 128K [11]. O produto por subscrição, não: o centro de ajuda da OpenAI documenta 272K para o Sol no ChatGPT Business [12], e o perfil que o servidor entrega ao cliente Codex caiu de 372.000 tokens brutos (353.400 efetivos) para 272.000 (258.400 efetivos) a 13 de julho, um corte de 26,9% [13].

Um responsável da OpenAI explicou publicamente que o perfil de 372K esgotava o uso das subscrições mais depressa do que o previsto e que a janela maior haveria de voltar [14]. A 29 de julho de 2026, a documentação continua a dizer 272K [12]. Em contraste, o Fable 5 e o Opus 5 correm com uma janela de 1M de tokens no Claude Code nos planos pagos [15].

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

A barra para onde olhar é a distância entre o que o modelo consegue conter e o que o produto lhe dá: o Claude Code corre hoje com quase quatro vezes a janela de subscrição do Sol, em modelos que competem diretamente [15].

O número importa por causa da compactação. O Codex compacta automaticamente as conversas longas, e o /compact resume a conversa visível para libertar tokens; a mesma página de boas práticas avisa contra levar um projeto inteiro numa única conversa [16]. Um resumo tem de escolher o que guarda, e as primeiras vítimas são precisamente as linhas sem brilho que mantêm um modelo na linha: as restrições negativas (“nada de engenharia a mais aqui”), os riscos aceites, a lista do que decidimos não construir. A documentação de subagentes da OpenAI até tem nomes para a avaria: context pollution e context rot [17]. A minha experiência com o Sol numa linha: nunca se esquece de como se escreve código. Esquece-se do que combinámos que não faria.

Porque é que o Ultra sabe a perda de controlo?

Porque o Ultra não é um contrato de chefe e operários. A documentação descreve o harness a lançar, encaminhar e recolher threads de agentes, mas em lado nenhum promete que o agente principal se limita a delegar; pode continuar a ler, raciocinar e implementar em paralelo com os seus próprios trabalhadores [17]. O modo acrescenta capacidade. Não acrescenta contenção.

As avarias que daí resultam estão registadas. Uma issue aberta do Codex descreve o parent a assumir que um subagente lento mas saudável encravou, e a refazer o trabalho em silêncio, com gasto duplicado de tokens e um contexto do parent inchado como resultado [18]. Um relatório detalhado de 24 de julho mediu os turnos puros de espera e de estado em 19,8% do volume bruto de tokens de um utilizador, com o modelo a reentrar a cada 30 a 60 segundos para sondar agentes que estavam ótimos [19]. É telemetria de utilizador, não dados de faturação, mas bate certo com o que o painel de progresso transmite visto de fora: um chefe incapaz de parar de verificar.

O meu pior caso foi estrutural. Um brief de arquitetura de sistema que o Fable 5 transformou num plano coerente em cerca de uma hora levou ao Sol Ultra cerca de quatro, a maior parte gasta a repartir um design fortemente acoplado por agentes paralelos e depois a reconciliar as suas suposições contraditórias. A equipa de engenharia da Anthropic chegou à mesma conclusão sobre a sua própria pilha multiagente: agentes paralelos compensam em trabalho em largura com fios independentes, programar costuma ter menos desses fios do que investigar, e as sessões multiagente deles queimaram cerca de 15 vezes os tokens de uma conversa normal [20]. Uma arquitetura é um único argumento. Dezasseis fragmentos bem fundamentados de um argumento não são a sua versão barata.

E depois há as avarias que não são lentas, são erradas no tempo. Duas vezes perguntei ao Sol em que ponto estava, recebi uma resposta razoável, e meia hora depois vi-o responder outra vez à mesma mensagem. O tracker do Codex tem relatos quase idênticos: uma sessão longa que devolve uma resposta idêntica à de muitos turnos antes [21], e um bug sobre responder a uma mensagem anterior em vez da última, fechado como duplicado de uma issue existente [22]. Quando isso acontece, deixo de tratar a thread como um colega e passo a tratá-la como um ficheiro corrompido: verifico o estado real com o git e a suíte de testes, e continuo numa sessão nova.

A auditoria que arrumou a questão para mim

Antes de uma release, apontei os dois laboratórios ao mesmo grande sistema de produção com o mesmo brief só de leitura: segurança, lógica, consistência entre serviços. O Sol Ultra voltou com cerca de 400 constatações, carregadas de severidade alta. O Fable 5 voltou com cerca de 70, com as críticas à cabeça e visivelmente indiferente à cauda de severidade média.

constatações do Sol Ultra

400

muita severidade alta, longa cauda média

constatações do Fable 5

70

mesmo brief, o crítico primeiro

As contagens não são a história; a composição é. Pus o Fable a triar as 400 do Sol como afirmações por provar, e aconteceram duas coisas. Descartou uma longa cauda de duplicados, edge cases teóricos e sugestões de endurecimento disfarçadas de bugs. E confirmou uma mão-cheia de problemas reais que ele próprio tinha falhado. A cobertura complementar é real. O ruído em que chega também.

Os primeiros números de benchmark da Artificial Analysis desenham a mesma silhueta: o Sol Max lidera o Coding Agent Index deles com 80, com o Fable 5 atrás, enquanto o Fable mantém um ponto de vantagem no índice de inteligência mais amplo, 60 contra 59, e uma vantagem clara na avaliação de qualidade analítica [23]. Cobertura e critério são competências diferentes. Neste momento, os laboratórios de fronteira vendem-nas em separado.

O meu erro na semana do lançamento foi o óbvio: disse ao Sol para corrigir as suas próprias constatações. O que voltou era defensável linha a linha e impossível de publicar como um todo, e passei um fim de semana a desfazê-lo. A OpenAI entretanto escreveu o fluxo correto na sua própria documentação de segurança: aceite uma constatação e gere um patch com limites, e explicitamente não peça ao agente para corrigir todas as constatações de um scan numa única conversa [24]; prefira a alteração segura mais pequena com evidência de regressão focada, uma constatação por tarefa [25]; e trate cada constatação importada como uma afirmação por provar até uma triagem só de leitura devolver um veredicto [26]. Um fabricante a documentar “não entregue ao modelo a sua própria lista de tarefas” é a honestidade de produto mais útil que li este ano.

Encontre tudo. Não toque em nada.

O enquadramento a que cheguei: o Sol é um instrumento de cobertura máxima. Apontado à descoberta, esse traço é uma prenda. Com autoridade sobre âmbito, orçamento e condições de paragem, o mesmo traço condensa-se em sessões de planeamento de quatro horas e backlogs de 400 entradas.

plano

• Fable 5 um contexto, uma arquitetura

spec congelada

auditoria

• Sol Ultra só de leitura, cobertura máxima

afirmações, não factos

triagem

• Fable 5 um veredicto por constatação

fila aceite

correção

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

Ao Fable pertencem a forma e os veredictos. Ao Sol pertence a cobertura. Quem implementa recebe um orçamento, não uma missão. São os detalhes aborrecidos que seguram o conjunto:

• As auditorias são só de leitura, com condição de paragem fechada. “Continua até não restarem problemas” é um convite que o Sol aceita sempre. “Uma passagem, um veredicto por constatação, e depois pára” é uma tarefa que ele termina.
• As correções levam orçamento de alteração. Uma constatação, ficheiros nomeados, um teto de linhas, nada de limpezas adjacentes:

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.

• A memória vive em ficheiros, não na conversa. As regras duradouras vão para um AGENTS.md pequeno [27]. O entregável atual e a sua condição de paragem vão para um goal, o mecanismo que a OpenAI desenhou para objetivos que têm de sobreviver à compactação [28]. As decisões e o estado vão para markdown versionado, que o guia da OpenAI para trabalhos de longo curso trata como a principal defesa contra a deriva [29]. A conversa é um canal de comunicação. O repositório é a memória.

Nada disto é um libelo contra o Sol. É o revisor de grande angular mais forte que já usei; encontrou problemas reais que o Fable falhou, e o mesmo tópico das 72 horas que documenta os seus piores ciclos também lhe credita ter quase reduzido para metade o tempo de execução de um pipeline paralelo complexo [4]. O Opus 5, defendi no texto anterior, é um ótimo funcionário que precisa de um chefe. O Sol é um investigador brilhante que precisa de um mandado: reviste tudo, não toque em nada, e cada afirmação passa por um juiz. A inteligência, nas duas casas, é real. O que você está a projetar agora é o organograma.