Você entrega ao Hermes um lote: oito subtarefas. Seis são buscas — ler um documento, rodar um grep num log, reformatar uma tabela. Duas são as difíceis — desembaraçar um bug de concorrência, redesenhar a fronteira de um módulo. E você tem um modelo só para todas. Escolha um caro e as seis tarefas triviais queimam dinheiro; escolha um barato e as duas difíceis voltam com bobagem plausível. Essa escolha forçada deixa de ser obrigatória com o PR #142563, mesclado em 22 de outubro de 2026.

A regra antiga: um delegation.model para cada filho

O modelo filho ficava fixado globalmente no config.yaml — delegation.model, delegation.provider, delegation.base_url. Na estratégia padrão, o delegate_task não tem parâmetro de modelo por tarefa, então cada subagente de um lote roda na mesma rota. A documentação dizia com todas as letras: para uma subtarefa sensível a qualidade, ou você deixa delegation.model sem definir naquela sessão, ou entrega o trabalho ao quadro kanban, que aceita, sim, uma sobrescrita de modelo por tarefa.

Então todo mundo fez o mesmo acordo: fixar um modelo de faixa intermediária e conviver com ele.

A regra nova: delegation.backend decide como o trabalho é roteado

A mudança em uma frase: a delegação virou uma categoria de provider plugável, com o mesmo formato de TTS, geração de imagens e backends de terminal. delegation.backend escolhe a estratégia. default significa exatamente o que você tinha — sem definir ou em default, o schema do delegate_task e cada definição de ferramenta do hermes-cli ficam idênticos byte a byte ao que eram.

As outras duas estratégias vêm do plugin oficial advanced-delegation:

• model_map — você lista opções com nome (fast, deep, …), cada uma com uma descrição de uma linha mais um provider e um modelo, e o modelo escolhe uma por tarefa;
• profile_routes — cada tarefa roda como um dos seus profiles do Hermes, com o modelo, as credenciais, as skills e a persona daquele profile.

delegation:
  backend: model_map
  backends:
    model_map:
      options:
        - name: fast
          description: Cheap and quick; lookups, summaries, simple edits.
          provider: openrouter
          model: google/gemini-3-flash-preview
        - name: deep
          description: Slow and careful; hard debugging and design work.
          provider: anthropic
          model: claude-opus-5
          reasoning_effort: high
          service_tier: fast      # opcional; recusado no spawn se esta rota não tiver nível fast
      default: fast                # opcional: opção para tarefas que não definem nenhuma
    profile_routes:                # lido quando backend: profile_routes
      profiles:
        - name: coder
          description: Writes and refactors code; runs tests.

As descrições não são enfeite. O modelo só vê os nomes e as descrições que você configurou — nunca os campos crus de provider, modelo ou chave. Escreva “Cheap and quick; lookups, summaries” e você está ensinando quando economizar; escreva “Slow and careful; hard debugging and design work” e você está ensinando quando gastar.

O core mantém todo o ciclo de vida dos dois jeitos: spawn, isolamento, papéis leaf/orchestrator, profundidade, concorrência, unidades em segundo plano, parada do fan-out, resultados, output_schema, progresso. Só a decisão de roteamento mudou de lugar.

Todo resultado roteado agora carrega um recibo route

Uma tarefa que passou por um backend informa onde realmente rodou: o backend, o nome da opção ou do profile, e o provider, modelo, esforço de raciocínio e nível de velocidade que o filho usou. Se um provider de fallback assumiu, fallback_activated é true.

Isso importa mais do que parece. Antes, você deduzia o modelo do filho a partir de “eu defini delegation.model”. Agora ele reporta — quando um lote de repente fica caro, você lê o recibo em vez de adivinhar.

Falhas são barulhentas, nunca uma troca silenciosa

É aqui que o PR gasta a maior parte do esforço:

• Se o backend selecionado está faltando (plugin não instalado ou desabilitado) ou informa que não consegue rodar, o delegate_task devolve um erro de ferramenta que nomeia o backend e a correção (instalar ou habilitar o plugin, /delegation default, ou hermes config set delegation.backend default). Nenhum subagente inicia, e os filhos nunca rodam em silêncio na rota padrão.
• Dentro de um lote, uma tarefa que o backend dela não consegue rotear — uma opção desconhecida, um parâmetro que o backend escolhido não aceita, um profile que não existe, um service_tier que a rota não oferece, um reasoning_effort desconhecido, credenciais ausentes — é recusada sozinha. A entrada de resultado dela tem status: "error", o motivo e route.refused: true; as irmãs seguem rodando.
• A chamada só se torna erro de ferramenta quando todas as tarefas foram recusadas.
• Uma rota de modelo sem fallback_providers próprios herda delegation.fallback_providers; fallback_providers: [] na rota desativa o fallback para ela. Uma rota de profile usa a cadeia de fallback daquele profile.

Um limite que vale conhecer: enquanto model_map ou profile_routes está ativo, delegation.model e delegation.provider ficam inativos — as rotas decidem. Não configure opções e depois se pergunte por que o antigo modelo fixo deixou de importar.

Trocar, e voltar atrás

As duas estratégias, o comando de barra /delegation e o hermes delegation config (criar, editar e excluir rotas de modelo, escolher profiles) vêm no plugin oficial:

hermes plugins search advanced-delegation
hermes plugins install advanced-delegation
hermes plugins enable advanced-delegation

Depois, trocar não exige editar arquivos:

/delegation model_map               # só nesta sessão
/delegation profile_routes --global # grava delegation.backend no config.yaml
/delegation default                 # volta para a estratégia padrão

Há uma sutileza que a documentação aponta explicitamente: trocar na sessão muda o roteamento, não o schema da ferramenta. Os parâmetros por tarefa (option, profile) fazem parte do prompt em cache e seguem o config.yaml, então mudam na sessão seguinte. Até lá o modelo pode ainda mandar o parâmetro do backend anterior — um option: fast depois de passar para profile_routes. Essa tarefa é recusada sozinha, com a correção na mensagem: /delegation <backend> --global e depois /new (porque o /new começa no backend salvo), ou /delegation <saved backend> para voltar. Ela nunca roda na rota padrão do novo backend só para continuar.

Sem o plugin, hermes config set delegation.backend default restaura o comportamento antigo.

Qual estratégia encaixa

• model_map — um conjunto de credenciais, dinheiro dividido por dificuldade. Tarefas leves vão para um modelo barato, as duras para um modelo forte. Encaixa em lotes cujas subtarefas variam muito em dificuldade: corrigir dez issues numa rodada, rodar vinte linhas de pesquisa.
• profile_routes — o filho troca de identidade. Cada profile carrega o próprio modelo, pool de credenciais, SOUL.md e política de terminal, o que encaixa em “estes subagentes devem rodar sob outras permissões”, por exemplo manter o trabalho de código dentro de uma política de terminal restrita.

Um aviso vem direto da documentação e merece citação: listar um profile em delegation.backends.profile_routes deixa os subagentes deste profile usarem as credenciais, o pool de credenciais, o SOUL.md e a política de terminal daquele profile. Liste só os profiles cujas chaves e cujo acesso ao terminal você aceita que este agente use.

Status do lançamento

O PR #142563 foi mesclado no main em 22 de outubro de 2026. O seguinte, #142564, move a própria estratégia padrão para um plugin incluído, e o #143126 acrescenta as configurações de delegação no desktop (seletor de modo, editor de rotas de modelo, rotas de profile). O lançamento mais recente é o v0.22.4, de 21 de outubro, então hoje tudo isso está só no main e chega ao canal estável na próxima versão. Se você trocar agora, atenção ao canal: releases de correção ainda não trazem isso.

Se você ainda não usou o controle de subagentes ao vivo (list/steer/stop), comece pelo guia de orquestração de subagentes. Para a seção delegation completa, a referência do hermes config é mais rápida que ler o código. A outra metade do roteamento por modelo está no guia de model_overrides, e a instalação de plugins está coberta no guia do catálogo de plugins.