Envias o Hermes a investigar um tema e ele monta uma “esquadra de pesquisa” — vários subagents a trabalhar em paralelo. Acabam todos por pesquisar a mesma keyword: uma vez, duas, quatro… e se estás num fornecedor de pesquisa pago, são cobranças reais, duplicadas. Ou fez scrape de uma página há dez minutos e agora volta a fazer scrape do mesmo URL do zero. O PR #94618, fundido a 25 de agosto, adiciona uma cache exatamente para estes casos: chamadas repetidas de web_search e web_extract dentro de 20 minutos deixam de voltar a cobrar ao fornecedor.

O que fica em cache: dedup de pesquisa + dedup de extração

A alteração toca em duas ferramentas:

• web_search: a mesma query dentro de 20 minutos vai à cache em vez da API de pesquisa do fornecedor. Pesquisas idênticas e concorrentes também são coalescidas (single-flight) — o primeiro chamador paga, os restantes partilham a resposta.
• web_extract: o mesmo URL dentro de 20 minutos é servido a partir do disco em vez de ser extraído novamente. A cache de extração é cross-process: CLI, gateway, cron jobs e subagents partilham-na todos.

Os números de validação são fáceis de apreciar: nos testes oficiais, pesquisar a mesma query duas vezes passou de 2 chamadas ao fornecedor para 1; quatro pesquisas idênticas e concorrentes de 4 para 1; extrair o mesmo URL duas vezes de 2 para 1.

Configuração: duas chaves, ativadas por defeito

web:
  cache_enabled: true        # ativada por defeito
  cache_ttl_minutes: 20      # TTL, intervalo de 1–1440 minutos

Ou através da CLI:

hermes config set web.cache_ttl_minutes 60   # estica o TTL para uma hora
hermes config set web.cache_enabled false    # desativa a cache por completo

Design de segurança: a cache nunca contorna as verificações

Caching parece simples, mas a implementação acerta em vários pormenores fáceis de estragar:

• A cache fica depois de todas as verificações de segurança: deteção de secrets em URLs, risco de SSRF (server-side request forgery), filtros de política, resolução do fornecedor — tudo corre primeiro, e só depois a cache participa. Um acerto na cache apenas salta o pedido de rede; nunca salta um portão de segurança;
• Só as respostas bem-sucedidas ficam em cache: pesquisas falhadas não deixam entrada na cache; respostas de resgate sem chave nunca são guardadas — o resgate one-shot continua one-shot;
• As entradas da cache são fatiadas por chamador: os resultados de pesquisa são agrupados em 10/20/50/100, para que limit=5 e limit=8 partilhem uma entrada, recebendo cada chamador a contagem que pediu;
• Páginas demasiado grandes não são indexadas: páginas acima de 2MB (o limite em disco) não entram no índice da cache, evitando que a cache devore o disco.

Onde as poupanças aparecem, e onde não aparecem

Maiores ganhos: investigação com subagents paralelos (a mesma query pesquisada por muitos agentes); extrações repetidas numa janela curta (conversas multi-turno a referenciar a mesma página); fluxos de trabalho mistos de cron e manuais (partilham a mesma cache de extração).

Quase impercetível: fluxos de trabalho em que cada query é nova e cada URL é obtido uma única vez — o caching não traz benefício, mas também quase não tem custo (uma consulta local por chamada).

Resumo

Uma cache de resultados de 20 minutos transforma “pesquisar, fazer scrape e cobrar repetidamente” em “pagar uma vez, partilhar com todos”. Ativada por defeito, TTL configurável, verificações de segurança primeiro — o tipo de mudança que só se nota quando a fatura fica melhor. Para mais mecanismos de poupança do Hermes, consulta o nosso guia de cinco canais de pesquisa gratuita e o compilado de quatro truques escondidos; a utilização completa das ferramentas web está na referência de comandos hermes.