You send Hermes to research a topic and it spins up a “search squad” — several subagents working in parallel. They all end up searching the same keyword: once, twice, four times… and if you’re on a paid search provider, those are real charges, duplicated. Or it scraped a page ten minutes ago and now re-scrapes the same URL all over again. PR #94618, merged on August 25, adds a cache for exactly these cases: repeat web_search and web_extract calls within 20 minutes stop re-billing the vendor.

What gets cached: search dedup + extract dedup

The change touches two tools:

• web_search: the same query within 20 minutes hits the cache instead of the vendor’s search API. Concurrent identical searches are also coalesced (single-flight) — the first caller pays, the rest share the response.
• web_extract: the same URL within 20 minutes is served from disk instead of re-scraped. The extract cache is cross-process: CLI, gateway, cron jobs, and subagents all share it.

The validation numbers are easy to appreciate: in official tests, searching the same query twice went from 2 vendor calls to 1; four concurrent identical searches from 4 to 1; extracting the same URL twice from 2 to 1.

Configuration: two keys, on by default

web:
  cache_enabled: true        # on by default
  cache_ttl_minutes: 20      # TTL, range 1–1440 minutes

Or via the CLI:

hermes config set web.cache_ttl_minutes 60   # stretch the TTL to an hour
hermes config set web.cache_enabled false    # turn caching off entirely

Security design: the cache never bypasses checks

Caching sounds simple, but the implementation gets several easy-to-get-wrong details right:

• The cache sits after every safety check: secret-in-URL detection, SSRF (server-side request forgery) risk, policy filters, provider resolution — all run first, then the cache participates. A cache hit only skips the network request; it never skips a safety gate;
• Only successful responses are cached: failed searches leave no cache entry; keyless-rescue responses are never cached — one-shot rescue stays one-shot;
• Cache entries are sliced per caller: search results bucket at 10/20/50/100, so limit=5 and limit=8 share one entry, each caller getting its requested count;
• Oversized pages aren’t indexed: pages over 2MB (the on-disk cap) don’t enter the cache index, keeping the cache from eating the disk.

Where the savings show up, and where they don’t

Biggest wins: parallel subagent research (the same query searched by many agents); repeated extracts in a short window (multi-turn conversations re-referencing the same page); mixed cron and manual workflows (they share the same extract cache).

Barely noticeable: workflows where every query is new and every URL is fetched once — caching brings no benefit, but also nearly no cost (one local lookup per call).

Summary

A 20-minute result cache turns “search, scrape, and bill repeatedly” into “pay once, share with everyone”. On by default, TTL-configurable, safety checks first — the kind of change you don’t feel until the bill looks better. For more of Hermes’ money-saving machinery, see our five free-search channels guide and the four hidden tricks roundup; the full web-tool usage is in the hermes command reference.