The latest documentation update for hermes-memory-installer brings a new section titled Claude-Obsidian Fusion, which catalogs six patterns for enhancing Knowledge Memory Management (KMM). Among these, Hot Cache is designated as P0 (priority zero) – the pattern the maintainers consider most critical for low-latency memory retrieval. If you are deploying Claude with an Obsidian vault as a persistent knowledge base, these patterns directly affect how you structure your memory layer. This post unpacks what the docs reveal, focusing on the Hot Cache pattern and why it deserves immediate attention.
What is hermes-memory-installer?
For those new to the tool, hermes-memory-installer is a CLI and library that bootstraps a memory system for AI assistants, with first-class support for Obsidian vaults. It handles the glue between Claude’s context window and external knowledge – indexing notes, managing retrieval, and caching intermediate results. The new documentation update formalises best practices that emerged from production use, codifying them as KMM enhancement patterns.
The six patterns are listed in the docs without deep explanation of each; only Hot Cache receives a full breakdown and is flagged P0. This suggests the other five are either simpler, less performance-critical, or still experimental. The fact that Hot Cache is tiered above the rest points to a real pain point: KMM can become the bottleneck in Claude workflows, and a hot cache is the quickest fix.
Hot Cache (P0) – What It Is and Why It Matters
According to the docs, the Hot Cache pattern maintains an in-memory cache of the most frequently accessed Obsidian notes (or fragments of them). When Claude needs to answer a query that references known data, the cache intercepts the request, avoiding a full vault scan or re-indexing. The pattern defines:
- TTL-based freshness – each cache entry has a configurable time-to-live.
- LRU eviction – when memory limits are hit, the least recently used entries are purged.
- Synchronisation hooks – when an Obsidian note is edited, the cache entry for that note is either invalidated or updated.
Why P0? Because without it, repeated queries against the same knowledge set force the system to read from disk or perform embedding lookups on every call. In practice, Hot Cache can cut average retrieval latency by over 80% for queries hitting cached data. The docs stress that this pattern should be enabled in any production deployment where response time matters.
Code Example: Configuring Hot Cache
The documentation includes a configuration snippet for the installer’s memory profile. This is what enabling Hot Cache looks like in memory.config.json:
{
"version": "1.2",
"kmm": {
"patterns": {
"hot_cache": {
"enabled": true,
"priority": "P0",
"ttl_seconds": 300,
"max_entries": 10000,
"eviction": "lru",
"sync_strategy": "invalidate_on_write"
}
}
}
}
The file is referenced during hermes-memory-installer apply and instructs the runtime to allocate a fixed-size cache. max_entries should be tuned to available RAM – the docs recommend ~10,000 entries per GB of heap. The sync_strategy field tells the cache to listen for Obsidian vault file change events and mark stale entries for lazy re-fetch. No manual cache warming is required; entries are populated on first access.
How the Cache Interacts with KMM
The Hot Cache sits between Claude’s context builder and the vault indexer. When a query arrives:
- The KMM layer checks the hot cache for matching keys (usually note titles or chunk hashes).
- On a hit, the cached content is returned immediately.
- On a miss, the vault is queried, and the result is inserted into the cache (if it meets a frequency threshold, also configurable under
min_access_count).
This two-tier approach mirrors classic system architecture patterns, but the nuance lies in the integration with Obsidian’s live data. Because notes can be edited at any time, the invalidation listener is crucial. The docs warn that without it, you risk serving stale knowledge inside Claude’s context – a subtle source of errors that can be hard to debug.
Where the Other Five Patterns Fit
The documentation update does not fully detail the remaining patterns, but they are named: Cold Storage, Semantic Prefetch, Context Weaving, Decay Scheduling, and Priority Tagging. Each addresses a different KMM concern – for example, Cold Storage handles large rarely-used corpora, while Decay Scheduling prunes stale knowledge over time. The maintainers have stated that a subsequent update will add full descriptions for those patterns. For now, their presence alongside Hot Cache suggests a coherent architecture: cache what is hot, archive what is cold, and let policies manage the gradient between them.
Practical Advice for Developers
If you are already using hermes-memory-installer, update to the latest version and open the claude-obsidian-fusion section of the docs. Enable Hot Cache in your memory configuration. Start with the default settings above, then adjust ttl_seconds based on how often your Obsidian vault changes. For a daily journal vault, a TTL of 300 s (5 min) is effective; for static reference notes, you can push it to 3600 s.
Do not overlook the sync_strategy parameter. The docs warn that invalidate_on_write has a slight overhead because the installer must watch the vault for changes. If that overhead is a concern, you can set sync_strategy: refresh_on_read and rely on TTL alone, but then you accept a window of staleness. For most deployments the impact is negligible.
Conclusion
The Claude-Obsidian Fusion documentation marks a shift from hermes-memory-installer being a mere setup tool to a system that encapsulates production knowledge patterns. The Hot Cache pattern (P0) is the most immediately actionable: it is simple to implement, yields large performance gains, and is well-documented with sensible defaults. The other five patterns add depth to the KMM model, but you should begin with Hot Cache. Your Claude instance’s reaction time will thank you.
Top comments (0)