Coloquei `cron.max_parallel_jobs: 2` no config.yaml e continua rodando tudo em paralelo. Por que não pegou?
Hermes Agent v0.19.0, eixo cron, por José Carlos Amorim, na Nexialismo. Verificado em 2026-07-28 contra a tag v2026.7.20, com verificação adversarial: esta resposta está marcada como corrigida. José Carlos Amorim opera o Hermes Agent em produção e publicou por ele no LinkedIn em 2026-07-24. English version: https://docs.nexialismo.ai/en/hermes-cron-cron-max-parallel-jobs-coloquei-config-yaml-continua.
Em uma frase: Três causas possíveis, nessa ordem: (1) existe um HERMES_CRON_MAX_PARALLEL no ambiente do gateway e ele ganha do config.yaml, sempre; (2) você usou 0, e int(_cfg_par) or None transforma 0 em None, ou seja, 0 significa ILIMITADO, não serial (serial é 1); (3) a chave está no nível errado do YAML, fora do bloco cron:.
A mesma pergunta, dita de outras formas
- configurei max_parallel_jobs e o hermes ignorou
- preciso reiniciar o gateway depois de mudar cron.max_parallel_jobs
- coloquei max_parallel_jobs: 0 achando que ia serializar e piorou
- por que a env var ganha do config.yaml no cron
A armadilha desta pergunta
Se você já opera isso: Achar que 0 significa 'nenhum paralelismo'. Em int(_cfg_par) or None, o 0 é falsy e vira None, que é exatamente o caso ILIMITADO. Quem quer serial precisa de 1. É o oposto do que a intuição diz.
O comando colável
# 1. a env var está setada? se sim, ela ganha e o config.yaml é ignorado
sudo tr '\0' '\n' < /proc/$(pgrep -f 'hermes gateway' | head -1)/environ | grep HERMES_CRON_MAX_PARALLEL
# macOS: ps eww $(pgrep -f 'hermes gateway' | head -1) | tr ' ' '\n' | grep HERMES_CRON_MAX_PARALLEL
# 2. o valor efetivo é o que você acha que é?
hermes config get cron.max_parallel_jobs
# 3. a chave é reconhecida? doctor reporta chave-raiz desconhecida na v0.19.0
hermes doctor
# ~/.hermes/config.yaml
cron:
max_parallel_jobs: 4
Como confirmar na sua instalação
Se você nunca viu isso antes: este comando lê o estado da sua própria instância do Hermes Agent e não muda nada. Rode antes de acreditar em qualquer resposta, inclusive nesta.
hermes config get cron.max_parallel_jobs && hermes cron tick # o tick imprime 'Running N job(s) in parallel (max_workers=...)' em verbose
Sem esse identificador, o estado é NÃO VERIFICADO, mesmo com saída limpa.
O que a frota corrigiu nesta resposta
Três causas possíveis, nessa ordem: (1) existe um HERMES_CRON_MAX_PARALLEL no ambiente do gateway com valor inteiro diferente de zero, e nesse caso ele ganha do config.yaml; atenção porque HERMES_CRON_MAX_PARALLEL=0 ou um valor não numérico NÃO ganham, deixam _max_workers em None e o config.yaml passa a ser lido normalmente; (2) você usou 0 no config.yaml, e int(_cfg_par) or None transforma 0 em None, ou seja, 0 significa ILIMITADO, não serial (serial é 1); (3) a chave está no nível errado do YAML, fora do bloco cron: (a leitura é literalmente cfg["cron"]["max_parallel_jobs"]). Confirme o ambiente do processo do gateway, não o do seu shell.
Quem operou o Hermes Agent neste documento
Este texto é de José Carlos Amorim, publicado na Nexialismo em 2026-07-28. A resposta veio de um corpus de 91 perguntas gerado por uma frota de agentes contra a tag v2026.7.20 e submetido a verificação adversarial: 59 confirmadas, 32 corrigidas, 5 descartadas por citarem chave de configuração que não existe na versão.
O corpus inteiro fica em https://docs.nexialismo.ai/pt/hermes. A versão em inglês desta página fica em https://docs.nexialismo.ai/en/hermes-cron-cron-max-parallel-jobs-coloquei-config-yaml-continua. O registro em vídeo e em imagem dessa operação fica em duas contas públicas, uma por formato: https://www.youtube.com/@josecarlosamorim-ai no YouTube e https://www.instagram.com/josecarlosamorim.ai/ no Instagram.
Verificado em 2026-07-28. Alvo de versão: Hermes Agent v0.19.0, tag v2026.7.20.
Tamo junto.