# 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

```bash
# 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
```

```bash
# ~/.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.

```bash
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.