Hermes reasoning effort: sessão, padrão global e ajuste por modelo

Manter o Hermes sempre no maior nível de reasoning não melhora toda tarefa, e ver thinking na tela não prova que a solicitação usou o nível escolhido. O fluxo mais seguro é manter um padrão global prático, elevar o esforço temporariamente em trabalhos difíceis, criar padrões por modelo apenas depois de evidências repetidas e confirmar o resultado com uma tarefa verificável e os registros reais do provedor.

Regra prática: comece em medium

O Hermes aceita none, minimal, low, medium, high, xhigh, max e ultra. Quando o valor não é definido, ele resolve para medium. Um modelo ou uma rota pode aceitar apenas parte dessa escala; o nível pode ser reduzido, traduzido, ignorado ou rejeitado. Consulte a documentação de configuração do Hermes e o registro da solicitação no seu provedor.

Tipo de tarefa	Ponto de partida	Quando mudar
Formatação, extração de campos ou reescrita determinística	low; teste minimal ou none somente após confirmar suporte	Suba para medium se houver campos ausentes ou formato quebrado
Pequena alteração de código, pergunta comum ou depuração bem delimitada	medium	Teste low após resultados consistentemente corretos; tente high se restrições forem ignoradas
Revisão com muitas condições, diagnóstico entre arquivos ou análise de trade-offs	high	Teste xhigh ou max só se o ganho se repetir e a espera for aceitável
Planejamento excepcionalmente difícil	Compare primeiro high e xhigh	Mantenha max ou ultra apenas se um teste controlado mostrar ganho útil

ultra é um degrau interno do Hermes. A rota o mapeia para o maior valor que consegue enviar, então não é um bom padrão global sem medição.

Exibir thinking não é o mesmo que alterar o effort

Estes comandos mudam o reasoning effort da sessão atual:

/reasoning high
/reasoning none

Estes comandos mudam apenas a exibição de thinking:

/reasoning show
/reasoning hide

Um thinking oculto ainda pode corresponder a uma solicitação em high. Um thinking visível não prova que o nível é alto. Execute /reasoning sem argumento para conferir separadamente o effort atual e o estado de exibição.

Quando usar sessão, padrão global ou regra por modelo

Sessão: uma tarefa difícil específica

Dentro de uma sessão ativa, execute:

/reasoning high

Por padrão, a mudança vale somente para aquela sessão. É a forma mais segura de dar mais esforço a uma depuração ou decisão pontual sem alterar todas as conversas futuras.

Para solicitar reasoning desativado na sessão:

/reasoning none

Isso só desativa o reasoning se o modelo e a rota permitirem. O provedor pode exigir reasoning, mapear o valor de outra maneira ou rejeitá-lo, por isso o registro real da solicitação continua sendo necessário.

Global: o padrão do dia a dia

Adicione --global para salvar o valor usado por novas sessões:

/reasoning medium --global

O Hermes persiste o valor em agent.reasoning_effort. Em uma carga variada, medium é uma base mais segura do que o nível máximo; aumente apenas as sessões que realmente precisarem.

Leia a configuração salva no terminal:

hermes config path
hermes config get agent.reasoning_effort
hermes config check

Um config get correto prova que o Hermes resolveu o valor. Não prova, sozinho, que o provedor o aceitou e aplicou sem alterações.

Por modelo: padrões estáveis ao alternar modelos

Se você muda com frequência entre um modelo rápido e outro de raciocínio mais profundo, edite config.yaml:

agent:
  reasoning_effort: "medium"
  reasoning_overrides:
    "custom/example-fast-model": "low"
    "custom/example-deep-model": "high"

Uma regra por modelo que corresponda ao model ID tem prioridade sobre agent.reasoning_effort. Prefira o model ID exato configurado no Hermes. Depois de editar, abra uma nova sessão, selecione o modelo desejado e execute /reasoning novamente.

Para ler o mapa:

hermes config get agent.reasoning_overrides --json

Model IDs costumam conter pontos e barras. Editar o YAML diretamente é simples; ao criar uma chave com ponto usando hermes config set, siga as regras de escape de ponto literal na referência da CLI.

Prioridade: por que mudar o valor global pode parecer não funcionar

Para o modelo selecionado, pense nesta ordem:

1. escolha temporária de /reasoning na sessão atual;
2. entrada correspondente em agent.reasoning_overrides;
3. agent.reasoning_effort global;
4. padrão do modelo ou do provedor.

Se o valor global for low, mas /reasoning continuar mostrando high, procure primeiro uma regra de sessão ou de modelo. Verifique novamente após /model, pois o novo modelo pode corresponder a outra entrada.

Use a mesma tarefa verificável

Não teste um nível em uma reescrita trivial e outro em um bug difícil. Isso mede tarefas diferentes, não o effort. O exemplo abaixo tem resposta verificável e não requer ferramentas:

A função deve unir intervalos inteiros fechados que se sobrepõem ou se tocam, sem reduzir uma cobertura existente.
Encontre um contraexemplo mínimo, informe a saída esperada e a real, faça a menor correção de código e adicione três testes de regressão.
Não use ferramentas. Retorne somente JSON com as chaves counterexample, expected, actual, fix e tests.

def merge_ranges(ranges):
    ranges = sorted(ranges)
    merged = []
    for start, end in ranges:
        if not merged or start > merged[-1][1] + 1:
            merged.append([start, end])
        else:
            merged[-1][1] = end
    return merged

A falha principal ocorre quando um intervalo posterior está totalmente contido no atual: atribuir o menor fim reduz a cobertura. Pontue cinco critérios objetivos em vez do estilo:

1. JSON válido sem texto extra;
2. contraexemplo de intervalo contido que realmente acione o bug;
3. expected e actual corretos;
4. correção mínima que preserve o maior fim;
5. testes para intervalos contidos, adjacentes e separados.

Comparação manual

Use uma sessão nova para cada nível candidato. Mantenha iguais o model ID, provedor, diretório, contexto, ferramentas, texto da tarefa e formato de saída. Uma execução basta para triagem; se a decisão mudar um padrão frequente, faça pelo menos três execuções limpas de cada finalista para não confundir variação aleatória com ganho estável.

Registre:

Campo	Como registrar
Effort	Execute /reasoning antes da tarefa e guarde o valor exibido
Qualidade	Use a escala objetiva de 0 a 5
Latência	Tempo real entre o envio e a resposta final
Modelo e provedor	Confirme no status do Hermes e no registro do provedor
Uso real	Use o registro da API ou o detalhamento de cobrança do provedor
Anomalias	Marque timeout, retry, fallback, erro ou troca de modelo

Não misture uma execução com retry ou fallback às execuções limpas. Ela pode mudar simultaneamente o modelo, o número de chamadas, a latência e os Token, impedindo isolar o efeito do reasoning effort.

Relatório local com --usage-file

Para uma comparação legível por máquina, altere temporariamente o nível global e execute a mesma tarefa one-shot:

hermes config set agent.reasoning_effort low
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-low-usage.json > ./hermes-low-output.txt

hermes config set agent.reasoning_effort medium
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-medium-usage.json > ./hermes-medium-output.txt

hermes config set agent.reasoning_effort high
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-high-usage.json > ./hermes-high-output.txt

No teste real, forneça o mesmo texto completo nas três execuções. Antes de começar, confirme que não há uma regra por modelo ocultando o valor global. Depois, restaure a configuração original. Se ela não estava definida:

hermes config unset agent.reasoning_effort

Se havia um valor explícito, configure-o novamente.

O JSON do Hermes pode incluir input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, total_tokens, api_calls, model, provider e estimated_cost_usd. Os contadores do nível superior cobrem o main agent loop. Chamadas auxiliares, como geração de título, vision ou compression, ficam em auxiliary; o total local combinado aparece em total_including_auxiliary.

Mantenha três limites claros:

• estimated_cost_usd é uma estimativa local, não a fatura do provedor;
• se o provedor não retorna uma categoria de Token, a ausência do campo não prova uso zero;
• quando houver retry ou fallback, confira chamadas e modelos reais no registro do provedor.

Separe quatro tipos de evidência

Uma verificação útil registra quatro coisas diferentes:

1. Leitura da configuração: hermes config get e config.yaml contêm o valor esperado. Isso prova o que o Hermes salvou e resolveu, não o que o provedor aceitou.
2. Effort realmente enviado ou mapeado: depois de escolher o modelo, execute /reasoning. Quando o status mostrar sends ... on this route ou a rota expuser um trace da solicitação de saída, confira se o valor enviado à API corresponde ao mapeamento esperado. A visibilidade de thinking continua sendo uma configuração de exibição separada.
3. Recebimento, aceitação ou execução pelo provedor: use um registro server-side da solicitação, um valor refletido ou uma confirmação explícita de aceitação/execução apenas quando a rota ou o provedor realmente expuser isso. O sinal de sucesso é o parâmetro registrado no servidor corresponder ao valor enviado/mapeado, sem rejeição, retry, fallback ou novo rebaixamento. Um payload trace prova recebimento, não execução; não exija campos que o provedor não oferece.
4. Uso e resultado: registre o modelo real, a qualidade da saída, a latência, as categorias de Token, as chamadas API e o custo cobrado ou estimado. Esses dados podem verificar a rota e o uso real, mas não o effort aceito pelo provedor; a quantidade de reasoning Token não permite deduzir o nível.

Esses tipos de evidência não substituem uns aos outros. Se o registro do provedor mostra apenas modelo, Token, número de chamadas ou gasto e não expõe effort, a conclusão defensável é que você comparou saída, latência e uso real sob as configurações registradas, mas não confirmou o nível aceito pelo provedor.

Quando none parece não ser salvo

Um issue público de 5 de outubro de 2026 relatou que, nos commits de main citados pelo autor, hermes config set agent.reasoning_effort none podia salvar YAML null, enquanto /reasoning none --global salvava a string none. É um relato de usuário limitado a versões específicas. Ele não prova que a sua versão atual ainda tenha o comportamento nem que uma versão posterior o tenha corrigido.

Verifique nesta ordem:

1. execute /reasoning none --global;
2. execute hermes config get agent.reasoning_effort;
3. abra o arquivo indicado por hermes config path e confirme que o valor é a string none, não vazio ou null;
4. inicie uma nova sessão e execute /reasoning outra vez;
5. se a rota ou o provedor expuser um registro server-side, um valor refletido ou uma confirmação explícita, compare o valor enviado/mapeado com o recebido ou aceito; se o registro contiver apenas modelo, Token ou gasto, anote que o effort aceito não pode ser confirmado em vez de inferi-lo.

Se o modelo exigir reasoning, talvez não seja possível desligá-lo. Use o menor nível aceito pela rota em vez de alterar repetidamente a exibição.

Provedor personalizado compatível com OpenAI

O comportamento efetivo depende do Hermes, do modelo e do provedor. Como exemplo, o guia do BetterToken para Hermes orienta configurar a própria API Key, a Base URL https://www.bettertoken.ai/v1 e o model ID exato do catálogo, e verificar a conexão com uma solicitação curta. O BetterToken não garante que todo modelo aceite todos os níveis nem que um nível maior melhore qualquer tarefa.

Com qualquer provedor, registre model ID, solicitação e uso real na mesma tabela. Caso contrário, uma troca despercebida de modelo, rota ou caminho de cobrança pode parecer um efeito do reasoning effort.

Escolha o menor nível que atinja sua meta de qualidade

Mantenha medium como base global, use o escopo de sessão para tarefas difíceis ocasionais e adicione high, xhigh ou nível superior por modelo somente após comparações repetidas mostrarem ganho estável. Para trabalho mecânico, reduza para low, minimal ou none apenas quando a qualidade continuar acima do limite e a latência medida ou o uso real melhorarem como esperado. Confira o mapeamento sends ou a aceitação/execução do provedor quando a rota expuser esse dado; caso contrário, registre o limite da evidência e não trate Token ou gasto como prova do nível aceito.

O melhor padrão não é o nível teoricamente mais forte. É o menor effort que atinge de forma consistente a qualidade desejada no seu modelo e rota, com latência e uso real aceitáveis.