Vous envoyez Hermes étudier un sujet et il lance une « équipe de recherche » — plusieurs subagents travaillant en parallèle. Ils finissent tous par chercher le même mot-clé : une fois, deux fois, quatre fois… et si vous êtes sur un fournisseur de recherche payant, ce sont de vraies facturations, dupliquées. Ou bien il a scrapé une page il y a dix minutes et rescrape à présent le même URL encore une fois. Le PR #94618, fusionné le 25 août, ajoute un cache précisément pour ces cas-là : les appels web_search et web_extract répétés dans les 20 minutes cessent de refacturer le fournisseur.

Ce qui est mis en cache : dédoublonnage des recherches + dédoublonnage des extractions

Le changement concerne deux outils :

• web_search : la même requête dans les 20 minutes touche le cache au lieu de l’API de recherche du fournisseur. Les recherches identiques concurrentes sont aussi fusionnées (single-flight) — le premier appelant paie, les autres partagent la réponse.
• web_extract : le même URL dans les 20 minutes est servi depuis le disque au lieu d’être re-scrapé. Le cache d’extraction est inter-processus : CLI, gateway, jobs cron et subagents le partagent tous.

Les chiffres de validation sont faciles à apprécier : dans les tests officiels, rechercher deux fois la même requête est passé de 2 appels fournisseur à 1 ; quatre recherches identiques concurrentes, de 4 à 1 ; extraire deux fois le même URL, de 2 à 1.

Configuration : deux clés, activées par défaut

web:
  cache_enabled: true        # activé par défaut
  cache_ttl_minutes: 20      # TTL, plage de 1 à 1440 minutes

Ou via la CLI :

hermes config set web.cache_ttl_minutes 60   # étendre le TTL à une heure
hermes config set web.cache_enabled false    # désactiver complètement le cache

Conception sécurité : le cache ne contourne jamais les vérifications

La mise en cache semble simple, mais l’implémentation traite correctement plusieurs détails faciles à rater :

• Le cache se situe après chaque vérification de sécurité : détection de secrets dans l’URL, risque SSRF (server-side request forgery), filtres de politique, résolution du provider — tout s’exécute d’abord, puis le cache entre en jeu. Un hit de cache ne saute que la requête réseau ; il ne saute jamais une barrière de sécurité ;
• Seules les réponses réussies sont mises en cache : les recherches échouées ne laissent aucune entrée de cache ; les réponses de secours keyless ne sont jamais mises en cache — un secours one-shot reste one-shot ;
• Les entrées de cache sont découpées par appelant : les résultats de recherche sont regroupés par paliers de 10/20/50/100, si bien que limit=5 et limit=8 partagent une seule entrée, chaque appelant recevant le nombre demandé ;
• Les pages trop grandes ne sont pas indexées : les pages de plus de 2 Mo (la limite sur disque) n’entrent pas dans l’index du cache, évitant que le cache ne dévore le disque.

Où les économies se voient, et où elles ne se voient pas

Plus gros gains : la recherche en subagents parallèles (la même requête cherchée par de nombreux agents) ; les extractions répétées dans une courte fenêtre (les conversations multi-tours qui référencent à nouveau la même page) ; les workflows mixtes cron et manuels (ils partagent le même cache d’extraction).

À peine perceptible : les workflows où chaque requête est nouvelle et chaque URL n’est récupéré qu’une fois — le cache n’apporte aucun bénéfice, mais aussi presque aucun coût (une seule consultation locale par appel).

Résumé

Un cache de résultats de 20 minutes transforme « chercher, scraper et facturer en boucle » en « payer une fois, partager avec tout le monde ». Activé par défaut, TTL configurable, vérifications de sécurité d’abord — le genre de changement qu’on ne remarque pas avant que la facture ne s’améliore. Pour en savoir plus sur les mécanismes d’économie de Hermes, voir notre guide des cinq canaux de recherche gratuits et le récapitulatif de quatre astuces cachées ; l’utilisation complète des outils web est dans la référence de la commande hermes.