GPT-6.1 Sol em COBOL: 86,6% contra 5,4%, e apenas um dos dois testes pode ser reexecutado

Em 19 de outubro de 2026, a O​penAI publicou duas avaliações de codificação para linguagens de baixos recursos, e o número de destaque pertence ao GPT-6.1 Sol: 86,6% das tarefas de migração de COBOL foram aprovadas com esforço de raciocínio baixo, contra 5,4% do GPT-5.6 Sol na mesma configuração, subindo para 97,9% quando o esforço aumenta. A segunda avaliação, MultiLangBench, é a história de um modelo diferente — GPT-6 Astra obteve uma média de 87,4% em vinte idiomas com esforço máximo — mas é a metade mais útil do lançamento, porque a O​penAI colocou seu harness no GitHub sob Apache-2.0 e você mesmo pode executá-lo hoje à tarde. A avaliação de migração de COBOL, a que traz os 86,6%, é outra questão: seus testes são ocultos, seu critério de aprovação é paridade de saída byte a byte em relação a casos que ninguém fora da O​penAI viu, e nenhum terceiro a reproduziu. Essa assimetria é a história toda, e vale a pena dizer isso claramente antes que qualquer um dos números seja citado em um caso de negócios de migração. As falhas documentadas de IA e os incidentes com agentes por trás de lançamentos como este estão reunidos em o OrcaRouter AI Incident Archive onde cada entrada traz suas próprias fontes, severidade, grau de confiança e indicador de disputa.

Uma data para não confundir. O próprio GPT-6.1 Sol é de 29 de setembro de 2026 — isto não é um lançamento, e nada aqui altera os pesos, o preço ou a tabela de tarifas do modelo. O que aconteceu em 19 de outubro foi que a OpenAI publicou evidências sobre o que o modelo pode fazer em uma categoria que ainda não havia documentado, e lançou um benchmark que qualquer pessoa pode executar novamente. É esse o evento sobre o qual este artigo trata.

O que foi realmente publicado e para que serve cada metade

As duas avaliações respondem a perguntas diferentes, e a própria formulação da OpenAI as separa. O MultiLangBench pergunta se um modelo consegue construir algo em uma linguagem na qual ninguém treina: implementar o SQLite 3.40.1 do zero em uma entre vinte linguagens de programação e, em seguida, passar por uma suíte de conformidade de banco de dados. A avaliação de migração de COBOL pergunta se um modelo consegue mover algo: traduzir programas COBOL para C++, Java, Kotlin, Python ou Rust preservando exatamente o comportamento observável.

O primeiro é um teste de nível mínimo de capacidade. O segundo é aquele com que as empresas realmente se importam, porque COBOL não é uma curiosidade de benchmark — estimativas de longa data da IBM colocam o COBOL por trás de mais de 40% dos sistemas bancários online e de cerca de 95% das transações de caixa eletrônico, e o código é mantido por uma força de trabalho que não está sendo substituída.

• MultiLangBench, esforço máximo — GPT-6 Astra 87,4%, GPT-6 Luna 40,3%, GPT-5.6 Sol 26,8%. Astra superou 83% em 19 de 20 linguagens; COBOL foi seu pior resultado, com 72,1%, contra 10,9% do GPT-5.6 Sol, o que mostra que a linguagem mais difícil do conjunto ainda é aquela com as ferramentas mais antigas.

• Migração de COBOL, baixo esforço — GPT-6.1 Sol 86,6%, GPT-5.6 Sol 5,4%, a um custo de API estimado em 61% do modelo mais antigo para a execução da avaliação, ou 39% menos.

• Migração de COBOL, maior esforço — GPT-6.1 Sol 97,9%, que a OpenAI descreve como próximo da saturação.

• Detalhamento por linguagem que a O​penAI divulgou — Fortran 83,5% para o Astra contra 21,4% para o GPT-5.6 Sol; Visual Basic 89,4% contra 27,5%; OCaml 85,8% contra 25,6%; GPT-6 Luna com 17,1% em COBOL, 31,4% em Fortran, 34,1% em OCaml e 41,6% em Visual Basic.

• Custo por amostra no MultiLangBench — uma estimativa de US$ 0,77 para o GPT-6 Luna contra US$ 3,48 para o GPT-5.6 Sol, cerca de 78% menor, que é o número que faz do modelo mais fraco da tabela o interessante para um pipeline de geração de builds.

A avaliação que você pode refazer: o que o MultiLangBench realmente pede

O repositório é github.com/openai/MultiLangBench, Apache-2.0, e ler o harness é mais informativo do que ler o ranking. A tarefa é específica o suficiente para que um modelo não consiga blefar: produzir um executável que recebe um caminho de banco de dados como argumento de linha de comando, lê uma consulta SQL da entrada padrão e se comporta como o SQLite 3.40.1. Os testes vêm da própria suíte TCL do SQLite — cerca de 51.000 testes no total, dos quais aproximadamente 24.000 foram convertidos nas triplas que o harness usa: um banco de dados inicial, uma consulta do usuário e uma consulta de validação. Os nomes dos testes são hashes SHA-256 desses componentes, então a suíte não pode ser memorizada pelo nome.

As regras são onde mora a dificuldade, e cada uma fecha um atalho:

• Sem internet e sem SQLite em lugar nenhum do ambiente. O harness diz para remover todos os vestígios do SQLite primeiro. Um modelo não pode executar o mecanismo real via shell nem buscar uma implementação.

• A validação é executada contra o SQLite 3.40.1 real. Sua implementação modifica o banco de dados; o harness o extrai e o verifica com o original genuíno. Comportamento aproximado falha.

• Sessenta segundos por teste, e uma resposta no idioma errado pontua zero. Misturar idiomas falha, e o harness observa que outro modelo pode ser usado para verificar em qual idioma você realmente escreveu. Essa última regra existe porque a trapaça óbvia — escrever em Python e encapsulá-lo — é a primeira coisa que um modelo capaz tenta.

• A execução rápida tem 272 testes, não 24.000. O README recomenda executar apenas os testes cujos nomes começam com 00, 01 ou 02 quando você quiser um número comparável. Esse é o detalhe a observar antes de comparar sua própria pontuação com a da O​penAI: uma execução do conjunto completo e uma execução rápida não são a mesma medição, e o README afirma isso.

Isso é um benchmark real e verificável. Também revela algo que a cobertura da imprensa não disse: o número principal de 87,4% foi medido em uma suíte que você pode aplicar ao seu próprio modelo, o que é raro o bastante para valer o download.

A avaliação que você não consegue reexecutar — e por que isso não é automaticamente um escândalo

A avaliação de migração de COBOL foi projetada, executada e pontuada pela OpenAI, e seus casos de teste não são publicados. O critério de aprovação é declarado com precisão — uma migração só conta se cada teste oculto produzir uma saída observável idêntica byte a byte — e essa precisão é exatamente o que torna o resultado não verificável de fora: os 86,6% são a medição da OpenAI contra os próprios casos ocultos da OpenAI. Apenas uma das duas avaliações no lançamento é algo que um leitor pode reproduzir.

Reter testes de migração não é indefensável. Presumivelmente, o corpus é extraído de programas legados reais, e publicá-lo pode vazar código de clientes ou entregar a modelos futuros um conjunto de treinamento. A paridade byte a byte também é um critério genuinamente conservador, mais rigoroso do que a maioria das avaliações de fornecedores: ele não recompensa uma tradução que seja apenas próxima.

Mas o critério também é onde começa o problema prático, e as próprias ressalvas da OpenAI apontam para isso. A saída da migração ainda precisa de revisão especializada e de testes em relação às regras de negócio e às dependências do sistema antes da produção. E a paridade de bytes é difícil exatamente nos pontos em que o COBOL é difícil: a linguagem trunca e arredonda a aritmética de ponto fixo de maneiras que a maioria das linguagens de destino não faz, então uma tradução pode parecer correta, passar em uma suíte que verifica "suficientemente próximo" e ainda assim alterar um saldo em um centavo. Uma suíte oculta que exige igualdade exata lida com isso; seu próprio processo de revisão também precisa lidar com isso, porque a pontuação do modelo não é uma declaração sobre seus programas.

O valor do custo exige o mesmo cuidado. A poupança de 39% é uma estimativa para a execução de avaliação — tokens de entrada e saída do benchmark —, não o custo de substituir um sistema em produção, que é dominado pela descoberta, revisão especializada, testes de integração e pelos anos de comportamento não documentado que nenhuma avaliação consegue amostrar.

O que 86,6% e 97,9% deveriam mudar em uma decisão

A leitura honesta é mais estreita do que as manchetes e mais útil do que elas. Uma linha de base de 5,4% não é um modelo que funciona pela metade; é um modelo que quase nunca produz uma tradução que preserve o comportamento, então a geração mais antiga nunca foi candidata para este trabalho. O GPT-6.1 Sol, com 86,6%, está na faixa em que a economia se inverte: uma ferramenta que rascunha a maior parte de uma tradução e deixa um revisor para verificá-la é um produto diferente de uma que não produz nada utilizável.

A taxa de 97,9% com esforço mais alto é o número que merece ceticismo, não porque esteja errada, mas porque está saturada. Quando um benchmark está perto do seu teto, ele deixa de distinguir entre modelos e passa a medir a suíte, e a OpenAI admite isso. Para planejamento, trate 86,6% com esforço baixo como o ponto de operação barato e 97,9% como o teto do que a avaliação pode mostrar — não como uma promessa de precisão para sua base de código.

Há também uma verificação cruzada que vale a pena fazer, e ela contraria o hype. No teste de build, COBOL permaneceu a linguagem mais fraca do GPT-6 Astra, com 72,1%, embora o Astra seja o modelo mais forte no geral, com média de 87,4%. A linguagem é difícil nas duas direções. Um modelo que migra bem COBOL em uma avaliação oculta não é, por isso, bom em COBOL; ele é bom no padrão que a avaliação amostra.

A outra coisa que aconteceu esta semana: a alegação sobre o traço de raciocínio

Uma postagem amplamente compartilhada em 21 de outubro afirmava que os traços de raciocínio do GPT-6.1 Sol são "totalmente legíveis, nada com que se preocupar". Nada na publicação da OpenAI de 19 de outubro, e nada na página de documentação do próprio modelo, sustenta que isso seja uma mudança no que a API retorna. O guia de raciocínio da OpenAI é explícito de que os tokens de raciocínio brutos não são expostos — os itens de raciocínio permanecem opacos — e que o que você pode solicitar é um resumo do raciocínio por meio do parâmetro summary, com o conteúdo de raciocínio criptografado sendo reproduzido entre turnos. O GPT-6.1 Sol oferece suporte à forma all_turns dessa reprodução. Um canal de resumo não é um traço legível, e tratar os dois como a mesma coisa é como uma alegação de segurança é feita por captura de tela.

O que é mensurável é adjacente e mais interessante para qualquer pessoa que audite um agente. A avaliação do Sonar de 9 de outubro do GPT-6.1 Sol, executada contra o GPT-6 Sol em esforço médio em 4.444 tarefas Java, constatou que os tokens de raciocínio caíram 51,4% — de 2,64M para 1,28M — enquanto a parcela de raciocínio na saída caiu de 41,8% para 19,5%, a saída aumentou e a taxa de aprovação funcional melhorou de 83,09% para 85,29%. A mesma execução constatou densidade de vulnerabilidades 32,4% menor, mas achados de confiabilidade de severidade crítica subiram de 21 para 46, com bugs de concorrência como a maior categoria, com 196 achados. Essa é uma troca sobre a qual um revisor pode agir. "Os traços são legíveis" não é, porque os traços não são o que está sendo retornado.

Para um projeto de migração, isso importa de uma forma concreta: sua trilha de auditoria é o diff e a saída dos testes, não a narração do modelo. Dimensione a capacidade de revisão de acordo — a constatação da Sonar de que 39,4% mais código gerado produziu 12.982 ocorrências no total, contra 9.859, é a forma do custo que se esconde por trás de uma pontuação de benchmark.

Conduzindo ambos os braços por conta própria

O problema prático de uma comparação como esta é que o braço de linha de base e o novo braço costumam ser dois contratos, duas chaves e duas relações de cobrança, o que gera atrito suficiente para que ninguém execute a linha de base. Ambos os modelos ficam no nosso catálogo atrás de uma única chave: openai/gpt-6.1-sol e openai/gpt-5.6-sol, aos preços de tabela da OpenAI com 0% de markup, ou seja, os mesmos US$ 2,00 de entrada e US$ 10,00 de saída por milhão de tokens que você pagaria ao fornecedor, com entrada em cache a US$ 0,10 e gravações de cache a US$ 2,50, e a faixa acima de 272K repassada a US$ 4,00, US$ 0,20, US$ 5,00 e US$ 15,00. Uma mudança de tarifa do fornecedor entra em vigor aqui no dia em que é publicada, e não na próxima revisão de contrato.

É essa passagem direta que torna barato executar um benchmark no mesmo dia: aponte o conjunto rápido do MultiLangBench para os dois modelos, pague o preço de tabela em cada um e você tem um número sobre a sua própria cadeia de ferramentas, e não sobre a da OpenAI. O failover automático é a outra metade do argumento — se o modelo mais novo se degradar no meio da execução ou uma rota sofrer limitação de taxa, a requisição não falha junto, e é isso que permite colocar um modelo ainda não comprovado à frente de um pipeline de migração antes de você ter evidências próprias.

A estrutura de testes MultiLangBench é pública, mas os casos de migração COBOL não são, então o único teste honesto dos 86,6% é aquele que você mesmo constrói: amostre algumas centenas dos seus próprios programas COBOL, traduza-os e compare a saída byte a byte com o comportamento original. Isso dá uma semana de trabalho e vale mais do que a tabela do fornecedor.

O que assistir a seguir

Três coisas mudariam esse quadro, e nenhuma aconteceu ainda. A OpenAI publicar os casos de migração de COBOL, ou um laboratório independente reexecutá-los, transformaria um número de fornecedor em uma medição. Um terceiro reproduzir a tabela por linguagem do MultiLangBench nos diria se os 72,1% do COBOL são uma propriedade da linguagem ou da suíte. E o registro independente do modelo em benchmarks — a Artificial Analysis atualmente coloca o GPT-6.1 Sol com um Intelligence Index de 52, em décimo segundo lugar entre 214 modelos, a 55,2 tokens de saída por segundo e US$ 0,72 por tarefa de índice — é a verificação que não depende em absoluto das próprias avaliações da OpenAI.

Até lá, o resumo útil é curto. O GPT-6.1 Sol é um modelo de 29 de setembro cuja capacidade de código legado foi documentada em 19 de outubro, em uma avaliação que você pode executar e uma que não pode. A executável diz que a nova geração está em outra classe em linguagens de baixos recursos. A não executável diz que a migração de COBOL agora vale um piloto. Apenas sua própria base de código pode transformar qualquer uma delas em uma decisão.