Uma "dieta de ferramentas" silenciosa: 6 definições de ferramentas emagrecidas, economizando 17%–44% de tokens por chamada

Já fez essa conta: toda vez que você pede ao Hermes para chamar uma ferramenta, o modelo precisa reler “como essa ferramenta é” do zero — parâmetros, formatos, pegadinhas, tudo detalhado numa definição JSON que viaja junto com cada requisição. Quanto mais longa a sua sessão e mais frequentes as chamadas de ferramentas, maior esse overhead fixo. Entre 27 e 28 de agosto, os mantenedores mesclaram seis PRs fazendo a mesma coisa: emagrecer as definições JSON das ferramentas. O resultado: process caiu de 306 para 228 tokens (−25%), todo de 323 para 232 (−28%), read_file de 426 para 244–269, skill_manage de 517 para 427 (−17%), video_generate de ~814 para 458/377, e browser_exec de 803 para 663 (−17%) — com zero mudança de comportamento em todas.

Por que vale a pena enxugar as definições de ferramentas

Vamos construir um modelo intuitivo primeiro. Quando o Hermes chama uma ferramenta, a requisição precisa incluir o schema JSON daquela ferramenta: description (o que ela faz), parameters (nome, tipo e restrições de cada parâmetro), enums e ressalvas. Essa definição viaja com cada requisição — não é um custo único; ela é reenviada em cada turno da sua conversa.

Se a definição da ferramenta A gasta 300 tokens e você a chama 50 vezes numa sessão, só essa definição queima 15.000 tokens. O Hermes vem com dezenas de ferramentas embutidas, e algumas definições pesadas (como os 800+ tokens do browser_exec) são um “imposto oculto” espremido dentro de toda requisição. Essa onda ataca exatamente essas fontes de imposto — sistematicamente, sob a campanha #95681.

O princípio: ensine cada fato exatamente uma vez

A ideia central dessa onda pode ser resumida numa frase: delete o ensino duplicado, mantenha as pegadinhas reais. Detalhando:

1. O enum É a lista de verbos (#97279 process, 306→228, −25%)

A descrição do process costumava re-listar todas as 8 ações (list, kill, submit…) com uma frase explicativa para cada uma. Agora: verbos autoexplicativos (list, kill) não ganham nada; os mecânicos mantêm uma oração cada; as partes realmente complicadas ganham mais ênfase — como a pegadinha write-vs-submit: “submit anexa Enter — use para responder prompts; write envia bytes brutos, sem newline. Em um PTY do Windows, um \n isolado não é um terminador de linha; o prompt simplesmente nunca retorna.”

2. O que o schema de parâmetros já ensina não é reensinado em prosa (#97257 todo, 323→232, −28%)

A descrição do todo costumava detalhar a estrutura dos items ({id, content, status}) em prosa — quatro linhas acima do schema JSON idêntico. A prosa duplicada desapareceu; o schema é a única fonte estrutural. As regras que sustentam tudo sobrevivem: enumere cada instância para tarefas de “todos os N items”, UM item em in_progress, completed apenas depois de verificado de verdade (nunca intenção), cancel-e-revise em caso de falha.

3. Capacidades anunciadas sob demanda (#97195 read_file, 426→244–269; #97095 video_generate, ~814→458/377)

A lista de formatos do read_file agora é gerada dinamicamente pela capacidade: se a sua instalação tem a extensão anydoc decide quais formatos são anunciados; formatos ausentes não são anunciados de forma alguma, e a mensagem de erro ensina como habilitá-los. O video_generate vai além: ele costumava mostrar 10 parâmetros estáticos para toda sessão, quatro dos quais se desculpavam por si mesmos (“ignorados por providers que não suportam”). Agora só os parâmetros que o backend ativo de fato honra são renderizados — negative_prompt, audio, seed, upscale aparecem apenas em backends que declaram suporte.

4. Deduplicação entre ferramentas (#97152 skill_manage, 517→427, −17%)

O mecanismo de patch do skill_manage usa a mesma semântica de find-and-replace fuzzy que a ferramenta patch (unicidade a menos que replace_all, contexto para unicidade, precisa diferir) — antes ensinada duas vezes. Agora o skill_manage diz “mesma semântica de matching da ferramenta patch” e mantém apenas os fatos específicos de skill (new_string vazio deleta). Também corrigiu uma ambiguidade real: file_path agora é explicitamente “relativo ao próprio diretório da skill, ex.: ‘references/api.md’ — sem barra inicial, nunca absoluto.”

5. Números falam (#96300 browser_exec, 803→663, −17%)

A dieta anterior do browser_exec incluiu uma verificação A/B: o schema enxuto alcançou paridade de acurácia com o original enquanto economizava 140 tokens por chamada.

Por que isso importa para você

  • Dinheiro economizado: é uma redução fixa de custo por chamada — quanto mais longa a sua sessão e mais chamadas de ferramentas, mais você economiza;
  • Mais confiável: schemas menores significam menor custo de compreensão para o modelo e menos chamadas com parâmetros errados;
  • Upgrade sem atrito: todas as mudanças são “zero mudança de comportamento”, com testes de contrato fixando cada ensinamento mantido — nada de “a ferramenta ficou mais burra depois do upgrade”.

Nota: essas mudanças foram mescladas entre 27 e 28 de agosto e atualmente vivem no main upstream, ainda sem tag de release. Assim que você rodar hermes update para uma build que as contém, elas entram em vigor automaticamente — nada para configurar.

Leitura adicional