O modelo que pensa pelo agente

Onde o Hermes guarda a escolha

A escolha do modelo e a credencial ficam em arquivos diferentes. O config.yaml do profile diz qual provedor e qual modelo usar. A credencial fica em outro lugar: a chave de API no .env, o login de uma assinatura no auth.json. Assim você troca de modelo sem mexer na chave. Um config.yaml copiado para outra máquina também não leva credencial junto.

O comando hermes model cuida das duas partes. Ele mostra a lista de provedores, solicita a credencial do escolhido e grava o modelo padrão. Rode o comando com o usuário hermes: rodado pelo administrador, ele grava tudo na pasta pessoal errada. Nesse caso, o agente não encontra a configuração.

Chave de API ou login de assinatura

A trilha mostra os dois jeitos de ligar um modelo. A diferença está em como você paga e em como a credencial chega ao Hermes.

Os dois convivem. Com as duas credenciais gravadas, o hermes model troca de um provedor para o outro sem solicitar a chave ou o login de novo. Num profile novo, o login da assinatura é compartilhado: os profiles leem o auth.json da pasta principal, porque esse tipo de login usa um token de renovação de uso único.

Troque o modelo na hora certa

O modelo padrão vale para as sessões novas. A conversa que já está aberta continua com o modelo com que começou, porque trocar o modelo no meio da sessão invalida o cache do provedor. O Hermes só faz essa troca com um comando seu. No Telegram e no Discord, as sessões em andamento também seguem com o modelo antigo até um hermes gateway restart.

Para trocar dentro da conversa, use o /model:

1
# mostra o provedor e o modelo da sessão
2
/model
3
# troca o modelo só desta sessão
4
/model NOME
5
# troca a sessão e grava como padrão no config.yaml
6
/model NOME --global
7
# usa o modelo só na próxima resposta
8
/model NOME --once

No gateway, a troca com /model sobrevive ao reinício do serviço. O /model reset volta ao padrão do profile sem apagar a conversa.

O principal e os auxiliares

O Hermes usa dois tipos de modelo. O principal é o que pensa: toda mensagem, todo passo com ferramenta e toda resposta passam por ele. Os auxiliares fazem trabalhos laterais, cada um com a própria configuração:

Por padrão, toda tarefa auxiliar fica em auto e usa o próprio modelo principal. Você só configura um auxiliar quando quer outro modelo naquele trabalho, pelo dashboard ou pelo bloco auxiliary do config.yaml.

Um modelo de reserva

Quando o provedor principal falha, por limite de requisições, servidor sobrecarregado, erro de autenticação ou queda de conexão, o Hermes pode trocar para um modelo de reserva no meio da sessão, sem perder a conversa.

O comando hermes fallback monta a lista com a mesma escolha de provedor do hermes model. Os subcomandos add, list, remove e clear editam a lista, gravada em fallback_providers no config.yaml.