Modelos melhores, ferramentas piores

• Na ferramenta de edição do Pi, Claude Opus 4.8 e Sonnet 5 acrescentaram campos inexistentes no esquema dentro de edits[], fazendo com que as chamadas fossem rejeitadas; observou-se que modelos mais recentes seguem esse esquema específico de ferramenta pior do que modelos anteriores
• Chamadas de ferramentas são um processo em que o modelo gera texto na forma de marcadores especiais e JSON, portanto, em amostragem sem restrições, convenções aprendidas podem se sobrepor ao esquema
• Nos casos de falha, oldText e newText em si estavam corretos, mas foram anexadas chaves falsas como requireUnique, oldText2, matchCase e in_file; a taxa de reprodução variou conforme o histórico do agente e a inclusão ou não de thinking blocks
• O Claude Code é um harness fechado, mas realiza muitas correções permissivas, como tentar novamente chamadas incorretas, aliases de parâmetros, ajuste de tipos, recuperação de Unicode e filtragem de chaves desconhecidas, e não usa o modo strict
• As chamadas de ferramenta em modo strict da Anthropic eliminaram esse problema; se esquemas de ferramentas alternativos ficarem em desvantagem à medida que o desempenho dos modelos melhora, o harness precisará de garantias mais fortes, como restrições gramaticais

---

Regressão observada na ferramenta de edição do Pi

• Ao rastrear uma issue do Pi, foi descoberto um problema em que os modelos Claude mais recentes adicionavam campos inexistentes dentro do array edits[] ao chamar a ferramenta de edição do Pi
• Isso apareceu não em um modelo pequeno, mas no Opus 4.8, e o mesmo comportamento foi confirmado também no Sonnet 5
• O mesmo problema não aparecia em modelos anteriores da Anthropic, então o modelo mais recente e de alto desempenho se comporta pior nesse esquema específico de ferramenta
• O Fable não foi testado porque havia a possibilidade de o classificador rebaixar silenciosamente a solicitação para o Opus

Chamadas de ferramenta são mais próximas de geração de texto

• Chamadas de ferramenta em LLMs funcionam fazendo o modelo receber o histórico da conversa, o prompt de sistema e a lista de ferramentas disponíveis, e então gerar um formato de chamada dentro de um grande prompt que contém marcadores especiais
• Os argumentos pretendidos de uma ferramenta de edição de arquivos podem incluir path e um array edits, como a seguir

{
  "path": "some/file.py",
  "edits": [
    {
      "oldText": "text to replace",
      "newText": "replacement text"
    }
  ]
}

• O harness valida os argumentos, aplica a edição e coloca o resultado de volta no modelo; se a validação falhar, o modelo vê o erro e normalmente tenta novamente
• O formato interno dos modelos da Anthropic não é público, mas marcadores ANTML já vazaram ou apareceram em comunicações públicas
• Esse formato parece XML, mas, em vez de XML de fato, está mais próximo de um sinal in-band conveniente para tokenização e treinamento
  • Parâmetros string de nível superior podem entrar inline
  • Arrays de objetos parecem entrar em forma serializada como JSON

Geração sem restrições e geração com restrição gramatical

• Há, em linhas gerais, duas maneiras de um modelo produzir saída estruturada
  • Pedir ao modelo que gere JSON compatível com um esquema e validá-lo depois
  • Impedir o sampler de amostrar JSON inválido ou formas que não sigam o esquema desde o início
• A segunda abordagem é chamada de decodificação consciente de gramática ou decodificação restrita, e mascara tokens que violariam a gramática
• Se o esquema permite apenas oldText e newText, o sampler pode impedir a geração de chaves como "in_file" ou "type"
• Sem essas restrições, o modelo gera seguindo convenções aprendidas em vez de seguir rigorosamente um contrato abstrato

Padrões reais de falha

• A ferramenta de edição do Pi usa um array edits porque suporta várias substituições exatas de strings em uma única chamada
• Nas chamadas com falha, campos não permitidos foram anexados assim

{
  "oldText": "...",
  "newText": "...",
  "requireUnique": true
}

{
  "oldText": "...",
  "newText": "...",
  "oldText2": "",
  "newText2": ""
}

• As chaves falsas observadas em experimentos repetidos foram variadas, incluindo type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, newText_2 e event.0.additionalProperties
• Nas chamadas incorretas confirmadas, os payloads reais de oldText e newText estavam corretos byte a byte, mas chaves sem sentido eram anexadas ao fim do objeto, fazendo a chamada ser rejeitada
• A reprodução depende muito do contexto
  • Não se reproduzia em um prompt novo de turno único como “edit this file”
  • Reproduzia-se em um histórico de agente em que o modelo lia o arquivo, diagnosticava o problema e compunha uma edição de múltiplas linhas
  • Era necessário ter a transcrição de Petr Baudis para conseguir reproduzir
  • Ao continuar a sessão desse usuário, o Opus 4.8 falhava em cerca de 20% das vezes
  • Ao remover os thinking blocks do histórico, a taxa de falha caía pela metade
  • Ao ativar chamadas de ferramenta em modo strict, o problema desaparecia naquela execução

Por que piorou

• A hipótese mais forte é que isso não é uma degradação aleatória de desempenho, mas um produto do treinamento
• Modelos anteriores da Anthropic foram treinados com algumas ferramentas, mas antes de harnesses fornecidos por usuários, como o Claude Code, se consolidarem como um objetivo claro
• É muito provável que modelos Anthropic mais recentes tenham passado por pós-treinamento incluindo o Claude Code ou um harness muito parecido, e que nesse ambiente tenham aprendido tanto chamadas de ferramenta bem-sucedidas quanto erros tolerados
• A ferramenta de edição do Claude Code não tem a estrutura aninhada edits[] do Pi, mas uma estrutura plana mais próxima de file_path, old_string, new_string e o opcional replace_all
• O cliente Claude Code corrige uma quantidade considerável de erros, como novas tentativas de uso incorreto de ferramentas, aliases de parâmetros, coerção de tipos, recuperação de Unicode e filtragem de chaves desconhecidas
• Se o aprendizado por reforço acontece dentro desse harness ou de uma simulação dele, uma chamada de ferramenta ligeiramente errada ainda pode concluir a tarefa e receber recompensa
• Quando outro harness oferece uma ferramenta de edição com o mesmo significado, mas em outro esquema, ela pode se tornar cada vez mais uma ferramenta fora da distribuição do ponto de vista do modelo
• Na época do lançamento do Opus 4.5, ele se adaptava muito bem a outras ferramentas de edição, mas a direção observada agora mostra que esquemas alternativos de ferramenta podem ficar em desvantagem em um ecossistema de ferramentas permissivo específico
• Existe uma text editor tool documentada, mas o Claude Code não segue exatamente esse formato, e o funcionamento interno do Claude Code não é visível por ser um harness de código fechado

O harness permissivo do Claude Code

• Embora o Claude Code seja de código fechado, o código reduzido mostra que ele é muito tolerante com os dados recebidos
• Ele verifica se markup <invoke vazou para o texto visível do modelo e, nesses casos, emite telemetria e tenta novamente a chamada incorreta usando sua própria máquina de estados
• Há recuperação de escapes Unicode que corrige sequências \uXXXX quebradas e lone surrogates dentro de valores string
• Também há aliases de parâmetros específicos por ferramenta
  • Edit aceita old_str, old_string, new_str e new_string
  • path é aceito como alias de file_path
• Chaves inesperadas são filtradas silenciosamente
• O modo strict não é usado
  • A Anthropic aplica limites de complexidade às definições de ferramentas no modo strict, o que pode fazer uma solicitação de API falhar
  • Esse parece ser o motivo pelo qual o Claude Code não tenta usar o modo strict

Modo strict e outros ecossistemas

• Como os modelos e harnesses da Anthropic são fechados, é difícil avaliar se o mesmo problema continuará em outros harnesses
• Os modelos Codex também são fechados, mas o harness não é fechado
• gpt-oss foi treinado explicitamente para usar o formato de resposta harmony da OpenAI, e há muitos documentos que mostram a forma de pensar da OpenAI sobre isso
• O harmony torna canais e tipos de conteúdo de chamadas de ferramenta parte do formato do prompt, e pode incluir marcadores como <|constrain|>json no corpo da chamada de ferramenta

<|start|>assistant<|channel|>commentary to=functions.get_weather
<|constrain|>json<|message|>{"location":"San Francisco"}<|call|>

• <|constrain|>json ajuda a stack de inferência a encontrar facilmente o limite em que deve mudar para amostragem com restrição de JSON no corpo da chamada de ferramenta
• Em modelos GPT hospedados, também há uma opção para fornecer uma gramática LARK para a gramática que as ferramentas do usuário devem seguir
• A Anthropic também parece fazer algo semelhante no modo strict, mas, em parâmetros de array aninhado, o modelo precisa gerar JSON com conteúdos longos de arquivo em múltiplas linhas escapados dentro de literais de string
• As chaves falsas aparecem logo depois de fechar uma string newText com centenas de tokens, em um ponto de alta entropia em que o modelo precisa escolher entre } e , "..."
• Opus 4.8 e Sonnet 5 parecem ter uma distribuição a priori mais forte para o formato de chamadas de ferramentas de edição, e essa distribuição a priori é mais próxima do esquema plano de edição do Claude Code
• O fato de o modo strict da Anthropic corrigir o problema pode ocorrer porque o lado do servidor rejeita a amostragem de chaves não permitidas pela estrutura do JSON Schema
• Nos modelos Codex testados, não foi observada uma regressão desse tipo, e o 5.6 ficou de fora por falta de acesso

Impactos para o design de harnesses

• Em modelos da Anthropic, o esquema de ferramentas pode não ser um contrato abstrato neutro
• Alguns formatos de ferramenta são próximos do que foi visto no pós-treinamento, enquanto outros são distantes
• Alguns formatos podem ser fáceis na codificação oculta do provedor, enquanto outros funcionam com dificuldade por exigir escrever um grande objeto JSON escapado dentro de um array aninhado após strings longas de múltiplas linhas
• Mesmo que o modelo entenda o esquema, sob pressão ele pode falhar ao amostrar a estrutura exata
• Na Anthropic, ativar a amostragem strict pode fazer esse problema desaparecer
• Ainda assim, o comportamento dos modelos mais recentes mostra o efeito do aprendizado por reforço sobre o modelo, e lutar contra a distribuição a priori de um harness específico pode ser desvantajoso para obter o melhor desempenho
• O Claude Code não é open source, e também não se sabe o que ele faz no ambiente de RL, então é difícil presumir que comportamentos treinados para o Claude Code se transferem de forma limpa para outras ferramentas
• Quanto mais pós-treinamento acontece dentro de um harness dominante, mais outros harnesses precisam herdar as peculiaridades desse harness
• A decodificação restrita pode ter trade-offs de qualidade, mas, se modelos mais recentes melhoram na capacidade de resolver tarefas enquanto pioram na capacidade de emitir fielmente esquemas alternativos de ferramentas, alguma parte do harness precisa de garantias mais fortes

[GN⁺]

Comentários no Lobste.rs

• Para quem está curioso sobre o Fable, entendo que agora o Fable sempre avisa explicitamente quando faz downgrade
  Eu também já caí no classificador; parece que “ordene os bugs por gravidade” soou como pesquisa de segurança

  • Pretendo fazer alguns testes
    Sei que disseram que não fariam isso às escondidas, mas ainda não consegui verificar o mecanismo usado para o downgrade

• Se essa hipótese estiver correta, o impacto pode ir além dos agentes de programação
  Qualquer aplicação que dependa de chamadas de ferramentas estáveis pode sofrer uma degradação de desempenho semelhante depois que o modelo for pós-treinado para o ambiente de execução preferido de um determinado provedor

• Para constar, este texto foi postado como ai, não como vibecoding
  É realmente difícil entender onde ficam os limites de vibecoding neste site
  Este texto tem muito mais a ver com o LLM de base, aprendizado por reforço e a criação do ambiente de execução ao redor disso
  Se até isso é vibecoding, não sei onde ainda sobra uso para a tag ai

  • Aqui, vibecoding acabou virando uma enorme letra escarlate aplicada a qualquer coisa que tenha, ou pareça ter, o menor contato com IA generativa
    Nas últimas semanas, posts de blog com tom “vibe”, READMEs de grandes projetos proibindo contribuições de LLM e até textos com frases demais do tipo “não X, mas Y” receberam todos a tag vibecoding
    Pessoalmente, desisti completamente de me importar com essa tag. A comunidade a aplica de forma tão reflexa que ela perdeu o significado real
    Dito isso, este texto específico é, por assim dizer, sobre modelos que de fato são usados para esse fim, então concordo com a tag vibecoding
    Ao mesmo tempo, pelo motivo exato apontado, também concordo que ai não deveria ser removida. Eu a adicionaria de volta, mas, por algum motivo, essa opção não aparece neste post

• Não surpreende. Dependência de fornecedor provavelmente faz parte do plano

  • Redução de custos também deve estar envolvida em algum grau. Se todo mundo usa Claude Code, o cache de prompts melhora
    A ideia de que “se você paga a assinatura do Claude e já envia todo o seu código para nós, também precisa usar uma UI gratuita que, separada do modelo, talvez não seja um mecanismo de dependência forte o bastante” é um pouco diferente de como a dependência pura de fornecedor costuma funcionar

• Faz sentido que um modelo funcione melhor no ambiente de execução em que foi treinado, ou seja, no ambiente criado pelos desenvolvedores do modelo
  Se ele passou por uma quantidade enorme de aprendizado por reforço em rastros como os do Claude Code, eu esperaria que ficasse bem pior em ambientes de execução que não se comportam como o Claude Code
  Pessoalmente, fiquei até mais surpreso por ele parecer se sair razoavelmente bem em ambientes de execução de terceiros, como o Pi
  Também parece plausível que o bug só apareça nas partes profundas dos rastros do agente
  No começo deste ano, nos modelos GPT 5.2 e 5.3, lutei com um bug em que, na parte final do rastro, o agente imprimia ls -ლა em vez de ls -la
  Registrei isso brevemente aqui: https://github.com/openai/codex/issues/7988
  Pela minha experiência, isso também só acontecia depois que o rastro ficava profundo
  Em contextos longos, o modelo parece deixar de “pensar” claramente e voltar a instintos primitivos
  Provavelmente é nesse ponto que a diferença entre a distribuição de treinamento do modelo e o ambiente de execução, ou a tarefa que o usuário força o modelo a realizar, afeta o desempenho de forma mais dramática

  • O problema não é fazer aprendizado por reforço para funcionar melhor no próprio ambiente de execução
    O problema é fazer aprendizado por reforço em excesso a ponto de regredir em outros ambientes de execução em comparação com a versão anterior
    Nesse ponto, é preciso fazer perguntas como: “será que outros tipos de overfitting também estão começando?”