Du schickst Hermes los, um ein Thema zu recherchieren, und es startet ein „Such-Team“ – mehrere Subagenten, die parallel arbeiten. Sie suchen am Ende alle nach demselben Keyword: einmal, zweimal, viermal … und wenn du einen kostenpflichtigen Suchanbieter nutzt, sind das echte, doppelte Kosten. Oder es hat vor zehn Minuten eine Seite gescraped und scraped dieselbe URL jetzt gleich noch einmal. PR #94618, gemerged am 25. August, fügt für genau diese Fälle einen Cache hinzu: Wiederholte web_search- und web_extract-Aufrufe innerhalb von 20 Minuten belasten den Anbieter nicht erneut.

Was gecacht wird: Such-Dedup + Extract-Dedup

Die Änderung betrifft zwei Tools:

• web_search: Dieselbe Query trifft innerhalb von 20 Minuten auf den Cache statt auf die Such-API des Anbieters. Gleichzeitige identische Suchen werden außerdem zusammengeführt (Single-Flight) – der erste Aufrufer zahlt, der Rest teilt sich die Antwort.
• web_extract: Dieselbe URL wird innerhalb von 20 Minuten von der Platte bedient, statt neu gescraped zu werden. Der Extract-Cache ist prozessübergreifend: CLI, Gateway, Cron-Jobs und Subagenten teilen ihn sich alle.

Die Validierungszahlen sprechen für sich: In offiziellen Tests reduzierte sich das zweimalige Suchen derselben Query von 2 Anbieter-Aufrufen auf 1; vier gleichzeitige identische Suchen von 4 auf 1; das zweimalige Extrahieren derselben URL von 2 auf 1.

Konfiguration: zwei Schlüssel, standardmäßig aktiviert

web:
  cache_enabled: true        # standardmäßig aktiviert
  cache_ttl_minutes: 20      # TTL, Bereich 1–1440 Minuten

Oder über die CLI:

hermes config set web.cache_ttl_minutes 60   # TTL auf eine Stunde ausdehnen
hermes config set web.cache_enabled false    # Caching komplett abschalten

Sicherheitsdesign: Der Cache umgeht nie die Prüfungen

Caching klingt einfach, aber die Implementierung bekommt mehrere leicht falschzumachende Details richtig:

• Der Cache sitzt hinter jeder Sicherheitsprüfung: Secret-in-URL-Erkennung, SSRF-Risiko (Server-Side Request Forgery), Policy-Filter, Provider-Auflösung – alles läuft zuerst, dann greift der Cache. Ein Cache-Treffer überspringt nur die Netzwerkanfrage; er überspringt nie ein Sicherheits-Gate;
• Nur erfolgreiche Antworten werden gecacht: Fehlgeschlagene Suchen hinterlassen keinen Cache-Eintrag; Keyless-Rescue-Antworten werden nie gecacht – One-Shot-Rescue bleibt One-Shot;
• Cache-Einträge werden pro Aufrufer geschnitten: Suchergebnisse werden in 10/20/50/100-Buckets aufgeteilt, sodass sich limit=5 und limit=8 einen Eintrag teilen und jeder Aufrufer seine angeforderte Anzahl bekommt;
• Übergroße Seiten werden nicht indexiert: Seiten über 2 MB (das On-Disk-Limit) gelangen nicht in den Cache-Index, damit der Cache die Platte nicht auffrisst.

Wo sich Einsparungen zeigen – und wo nicht

Größte Gewinne: parallele Subagenten-Recherche (dieselbe Query, von vielen Agenten gesucht); wiederholte Extracts in kurzer Zeit (Multi-Turn-Konversationen, die sich wieder auf dieselbe Seite beziehen); gemischte Cron- und manuelle Workflows (sie teilen sich denselben Extract-Cache).

Kaum spürbar: Workflows, in denen jede Query neu ist und jede URL nur einmal abgerufen wird – Caching bringt keinen Nutzen, kostet aber auch fast nichts (ein lokaler Lookup pro Aufruf).

Zusammenfassung

Ein 20-Minuten-Ergebnis-Cache verwandelt „immer wieder suchen, scrapen und abrechnen“ in „einmal zahlen, mit allen teilen“. Standardmäßig aktiv, TTL konfigurierbar, Sicherheitsprüfungen zuerst – die Art von Änderung, die man erst merkt, wenn die Rechnung besser aussieht. Weitere Geldspar-Mechanismen von Hermes findest du in unserem Leitfaden zu fünf kostenlosen Suchkanälen und dem Überblick über vier versteckte Tricks; die volle Nutzung der Web-Tools steht in der Befehlsreferenz zu hermes.