Modelos melhores, ferramentas piores: a regressão oculta do Claude

O problema com o Pi

No dia 4 de julho de 2026, o renomado arquiteto de software e criador de tecnologia Armin Ronacher trouxe a público uma descoberta técnica que expôs um comportamento problemático nos modelos de inteligência artificial mais avançados da atualidade. Ronacher revelou que, após passar dois dias investigando um erro atípico na ferramenta de edição de código de código aberto Pi, identificou uma regressão gritante na capacidade dos novos modelos da Anthropic de executar chamadas de função (tool calling). O problema, surpreendentemente, não se manifesta em modelos menores ou antigos, mas sim nas versões topo de linha do ecossistema, como o Opus 4.8 e o Sonnet 5, que passaram a falhar sistematicamente ao interagir com o Pi devido à inserção de argumentos inexistentes e malformados que violam o esquema estrutural de dados esperado pela plataforma.

A falha identificada por Ronacher no Pi ocorre de forma frustrante no array estruturado edits[], onde o modelo decide, por conta própria, inventar chaves adicionais que não constam no esquema de validação de dados. Embora o erro de formatação em si não seja incomum em modelos de linguagem menores e menos treinados, a surpresa da comunidade técnica reside no fato de que o Opus 4.8 e o Sonnet 5 performam muito pior do que as variantes anteriores da mesma família quando submetidos a esquemas de ferramentas altamente específicos e aninhados que utilizam codificação em formato JSON. Esse cenário levanta uma discussão profunda sobre os rumos do treinamento de grandes modelos de linguagem (LLMs) e a fragilidade de suas capacidades estruturais diante de atualizações de software e rotinas de pós-treino.

Durante seus experimentos com as APIs da Anthropic, Armin Ronacher fez uma escolha técnica notável ao decidir não testar o modelo Fable para este diagnóstico específico de inferência. A justificativa para essa exclusão voluntária baseia-se na incerteza acerca dos classificadores automáticos de tráfego que rodam nos servidores de backend, os quais poderiam rebaixar silenciosamente as requisições do Fable de volta para o modelo Opus sem o consentimento do usuário, misturando os dados experimentais e impedindo uma análise isolada do comportamento de cada modelo da família Claude.

Como as chamadas funcionam

Para compreender por que o Opus 4.8 e o Sonnet 5 falham de maneira tão peculiar no Pi, é indispensável examinar o funcionamento interno de uma chamada de ferramenta por um modelo de linguagem, partindo do princípio de que essas chamadas não passam de strings de texto puro interpretadas nos bastidores da API. O LLM não possui uma conexão nativa ou mágica com o sistema de arquivos remoto; ele simplesmente processa um fluxo contínuo de tokens de texto, composto pelo histórico da sessão ativa, o prompt de sistema e uma descrição estruturada das ferramentas de software disponíveis para que ele as acione por meio de marcações textuais específicas.

Sob esse aspecto conceitual, o servidor de inferência pega as definições estruturais das ferramentas fornecidas pelo interpretador do Pi e as injeta no prompt principal por meio de sinalizações internas conhecidas como in-band signaling. O modelo, tendo sido exaustivamente treinado em milhares de exemplos estruturados com esse formato de transmissão, emite em determinado momento de sua geração textual uma sequência que o interpretador da API (ou harness do cliente) reconhece como uma chamada estruturada de função, esperando uma estrutura de dados de caminho em path e uma lista contendo substituições precisas de conteúdo no parâmetro edits em formato JSON.

A serialização de dados nas chamadas do ecossistema Anthropic ocorre por meio de tags inspiradas em XML que vazaram publicamente sob a denominação de marcadores ANTML. Na prática, quando o modelo decide chamar uma ferramenta de edição de arquivo, ele gera uma cadeia textual contendo estruturas sintáticas como <antml:function_calls> e <antml:invoke name='edit'>, onde os parâmetros planos de arquivo são transmitidos diretamente nas tags de parâmetros <antml:parameter name='path'> e os parâmetros de coleções mais complexas são injetados em tags como <antml:parameter name='edits'> em formato de strings brutas de arrays JSON serializados.

Existem hoje duas metodologias principais para garantir que um modelo de inteligência artificial produza uma estrutura de dados perfeitamente limpa e sem erros de sintaxe em formato JSON. A primeira consiste em realizar uma validação reativa a posteriori, onde o interpretador lê o texto gerado livremente pelo modelo e, caso encontre falhas estruturais, emite uma mensagem de erro na conversa e aguarda uma nova geração; a segunda abordagem é a técnica de decodificação restrita por gramática (grammar-aware decoding), em que o amostrador (sampler) de tokens do servidor mascara os caminhos matemáticos de probabilidade, impedindo a geração de qualquer caractere ou chave que fuja do esquema formal.

A falha do Opus

A falha persistente documentada no interpretador do Pi demonstra que o amostrador flexível da Anthropic permite que o modelo Opus 4.8 sofra de alucinações estruturais graves exatamente ao finalizar a transmissão de blocos longos no array edits. Em vez de limitar-se às chaves restritas e exigidas pelo esquema (oldText e newText), o modelo gera chaves inventadas como requireUnique: true ou cria ramificações redundantes com os nomes fantasmas de oldText2 e newText2. Esse comportamento compromete a automação porque o interpretador do Pi descarta o payload estruturado devido à presença de propriedades adicionais desconhecidas no JSON, forçando ciclos repetitivos de requisições malogradas.

A variedade de anomalias que Ronacher registrou nos testes estruturais do Pi assemelha-se a um zoológico de termos arbitrários gerados pelo Opus 4.8 e pelo Sonnet 5 ao longo das sessões. O desenvolvedor documentou o surgimento de chaves espúrias adicionais tais como type, id, kind, unique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText_2, newText_2 e até mesmo a propriedade complexa event.0.additionalProperties no interior do objeto edits. Curiosamente, as strings reais contidas em oldText e newText mantinham-se bytes-corretas, provando que a lógica de substituição de código estava correta, mas a estrutura externa do JSON era arruinada na saída de amostragem de tokens.

O surgimento de erros estruturais mostrou-se extremamente dependente do histórico de conversas do agente inteligente em execução, não sendo reproduzível em interações limpas de turno único. Enquanto comandos diretos e isolados para editar um arquivo de código resultavam em estruturas válidas geradas pelo Opus 4.8 e pelo Sonnet 5, logs complexos compostos por múltiplas leituras de arquivos, diagnósticos de erros e edições em cadeia de múltiplas linhas de código disparavam consistentemente a falha estrutural do sistema.

Para validar estatisticamente essas falhas de modo reprodutível, Armin Ronacher fez uso de históricos de sessões de desenvolvimento reais disponibilizados pelo pesquisador e engenheiro Petr Baudis. Com base no material cedido por Baudis, foi possível determinar que o modelo Opus 4.8 falhava nas requisições estruturadas enviadas ao Pi em cerca de 20% de todas as tentativas diretas de modificação de código no projeto.

No processo de mitigação desse bug estrutural de 20%, o desenvolvedor Armin Ronacher identificou duas relações técnicas relevantes nos logs obtidos com Petr Baudis. A exclusão completa dos blocos de pensamento (thinking blocks) do histórico das conversas reduzia a taxa de falha de amostragem estrutural del modelo pela metade; paralelamente, a ativação do recurso de chamada estrita de ferramentas (strict tool invocation) fornecido pelo backend da Anthropic eliminava completamente o aparecimento de chaves adicionais inventadas nas execuções simuladas.

O ecossistema do Claude

A grande interrogação levantada pela comunidade técnica refere-se ao motivo técnico pelo qual os modelos Opus 4.8 e Sonnet 5 exibem uma regressão de desempenho em relação a formatos de ferramentas estruturadas quando comparados aos seus antecessores. A principal hipótese proposta por Armin Ronacher baseia-se no viés induzido durante as etapas de pós-treino e aprendizado por reforço (RL) da Anthropic, as quais parecem ter sido massivamente otimizadas e moldadas em torno de sua própria ferramenta interna de desenvolvimento baseada em console, o cliente proprietário Claude Code.

Diferentemente da estrutura hierárquica e aninhada do Pi, a ferramenta de edição nativa do Claude Code emprega um formato essencialmente plano, aceitando os parâmetros diretos file_path, old_string, new_string e um sinalizador opcional batizado de replace_all. À medida que o modelo de inteligência artificial é treinado iterativamente para interagir prioritariamente com essa interface da própria fabricante, ele desenvolve um viés matemático (prior) muito rígido a respeito de como uma chamada de modificação de código deve ser formatada.

A investigação minuciosa do código-fonte minificado do cliente do Claude Code revelou que a Anthropic implementou uma infraestrutura de cliente que funciona essencialmente como uma "harness de tolerância a slop" (slop harness). O software foi desenhado para absorver, ocultar e corrigir de modo silencioso os desvios de geração cometidos pelos modelos Claude nos bastidores, mitigando erros estruturais para que o usuário final receba a execução das tarefas sem travamentos no terminal de comando do desenvolvedor.

Dentro dos mecanismos tolerantes embutidos no Claude Code, o interpretador realiza monitoramento e varredura do texto de saída gerado pelo modelo à procura de vazamentos das tags brutas <invoke> que escapam da camada interna de inferência, registrando dados em telemetria e gerando rotinas automatizadas de repetição de comandos empurrados de volta ao modelo.

Esse harness de tolerância também executa rotinas dedicadas ao reparo de escapes Unicode malformados e inconsistências em caracteres especiais de texto que apresentem falhas em sequências como \\uXXXX ou pares substitutos inválidos. Adicionalmente, o cliente tolera aliases alternativos para os parâmetros da ferramenta oficial de modificação, aceitando intercambiavelmente chaves como old_str (remanescente do oficialmente documentado text editor tool), old_string, new_str, new_string, além de traduzir path diretamente como sinônimo do parâmetro file_path, limpando e ignorando qualquer propriedade estranha gerada pelo LLM.

A consequência desse design excessivamente permissivo no ecossistema do Claude Code reflete-se no algoritmo de aprendizado por reforço (RL) ao qual os modelos são submetidos. Como as chamadas de ferramentas imperfeitas e sintaticamente desalinhadas são corrigidas de forma invisível pelo cliente sem que a tarefa falhe, o modelo continua recebendo pontuação positiva e recompensas de otimização matemática, eliminando qualquer gradiente de punição contra a geração de aliases ou a inclusão de parâmetros arbitrários.

"O modelo aprende como é uma chamada de ferramenta bem-sucedida naquele ambiente. Ele também aprende quais erros são tolerados por aquele ambiente."

Com isso, ao ser acoplado a um ambiente com validação estrita que não perdoa erros estruturais, como é o caso do interpretador do Pi, o modelo Opus 4.8 e o Sonnet 5 deparam-se com uma situação fora de sua distribuição estatística usual de treinamento (off-distribution). Sob o peso acumulado de turnos de diálogo extensos, os modelos tentam fundir os dados hierárquicos do Pi com o layout plano do Claude Code (e sua flag de controle replace_all), ocasionando o estouro de parâmetros inválidos como requireUnique no ponto crítico onde o modelo encerra a geração de longas literais de texto.

Este padrão regressivo representa uma mudança preocupante quando comparado ao histórico de lançamento do modelo predecessor Opus 4.5. Naquela versão anterior de desenvolvimento, Armin Ronacher havia testemunhado uma flexibilidade e habilidade de adaptação excepcionais por parte do modelo da Anthropic em relação a diferentes especificações de ferramentas, indicando que os modelos mais antigos lidavam melhor com ecologias de ferramentas não documentadas e variadas do que as variantes atuais hiper-treinadas para clientes fechados.

A alternativa da OpenAI

O cenário de degradação comportamental provocado por pós-treinamento excessivo não se manifestou, contudo, nos testes realizados por Ronacher com as arquiteturas de inteligência artificial de outras desenvolvedoras de destaque do mercado. Os modelos de inferência do ecossistema Codex mantidos pela OpenAI exibiram estabilidade no manuseio de ferramentas estruturadas em esquemas customizados de dados, sendo que o desenvolvedor ressalvou apenas não ter testado a versão do Codex 5.6 por não possuir chaves de acesso ativas para esse modelo em julho de 2026.

A abordagem técnica da OpenAI para contornar problemas de conformidade sintática nas chamadas de ferramenta assenta-se no protocolo Harmony, um formato de prompts de baixo nível que estruturalmente integra canais de dados e restrições sintáticas diretamente no stream de geração de tokens. O Harmony emprega marcadores explícitos de sinalização, como as tags <|constrain|>json e referências a canais de função como functions.get_weather passando dados de parâmetros estruturados como San Francisco, instruindo o amostrador em tempo real a impor regras rígidas de validação do formato JSON.

Ao passo que o ecossistema fechado do Claude Code da Anthropic oculta seus esquemas de dados e comportamentos internos em códigos minificados sem documentação pública clara para desenvolvedores de software independentes, o ecossistema Harmony da OpenAI fornece recursos de estruturação consistentes, suportando a declaração de gramáticas especializadas sob o formato LARK para controlar rigorosamente os delimitadores e chaves possíveis nas respostas estruturadas.

Por fim, a relutância em adotar de modo integral o modo estrito de chamadas no próprio console do Claude Code aponta para as limitações estruturais impostas pela infraestrutura de API da Anthropic. Como as definições complexas e ricas de esquemas de funções superam com facilidade os limites tolerados de complexidade sintática para ferramentas no modo estrito executado do lado do servidor, o cliente oficial é forçado a operar em modo aberto de flexibilidade, perpetuando o ciclo que incentiva os modelos a alucinar parâmetros adicionais nos ambientes de execução.

O impacto para desenvolvedores

Para a comunidade de desenvolvedores de software que utilizam e implementam agentes inteligentes autônomos, as investigações técnicas realizadas no Opus 4.8 e no Sonnet 5 servem como uma severa constatação prática a respeito das dinâmicas de engenharia de prompts e integrações. O estudo comprova que mesmo os modelos mais capacitados do ponto de vista conceitual e de raciocínio verbal podem sofrer de degradação estrutural devido ao viés introduzido por harnesses condescendentes de terceiros.

Para contornar esses obstáculos sintáticos nos sistemas corporativos de automação, engenheiros de tecnologia precisam focar na aplicação rigorosa do modo de chamadas estritas (strict tool invocation) em suas arquiteturas de integração ou construir validadores e parsers locais resilientes. A dependência de modelos de ponta sem a imposição de filtros e gramáticas controladoras de amostragem deixa os sistemas vulneráveis a falhas silenciosas provocadas por atualizações opacas nos ecossistemas de inteligência artificial das grandes fabricantes.