Memory Recall

The Memory Recall node (class ECHOContextNode) promises to retrieve context from a four-tier memory system - hot (GPU VRAM), warm (system RAM), cold (NVMe), archive (network) - and hand you the relevant context for your prompt. That's a genuinely interesting architecture for people who keep regenerating with long prompt context. Here's the catch, from the source: it can't recall anything, because nothing ever gets written to that memory. Every query returns the same placeholder: [No cached context for query: ...].

The tiered-memory idea, explained

Four-tier memory (hot/warm/cold/archive) is real architecture - the README ties it to "ECHO 2.0" and it borrows the mental model from how LLM serving stacks cache: GPU VRAM holds what's actively being used, RAM holds recent stuff, NVMe holds the historical pile, and network is the full archive. The search_tiers dropdown - hot_only, hot_warm, all_tiers - controls how deep you dig. The design intent is that repeated prompts get faster, and that same query → same context, deterministically.

What actually happens

Walk through retrieve in the source and you'll see: it picks your tier order, and for each tier it checks whether a directory exists at <echo_cache_path>/<tier>. That's it. There's no code path that ever reads a file, computes a match, or appends anything to the context. The search is scaffolded out - marked "// Deterministic: hash-based selection" - but the retrieval logic never runs, and since context_parts stays empty, the context output is always the no-context placeholder string. The retrieval_log output at least tells the truth in structure: it reports which tiers were "searched" (i.e. which directories exist), your query preview, and the context_budget.

Two practical notes. First, context_budget (default 2048, range 256–16384) only matters if there is context to trim - today it truncates the placeholder. Second, the default echo_cache_path is .echo-curator, and you'll notice the repo's .gitignore lists .echo-curator - the author's own machine has such a directory, so this is clearly meant to integrate with some curator tool that writes context files there. Until that tool, or a write path in this node, exists, there's nothing to recall.

Inputs and outputs, for the record

• query (STRING, multiline) - the thing you're recalling context for.
• context_budget (INT) - max characters of context to return.
• search_tiers (enum: hot_only / hot_warm / all_tiers) - depth of search.
• echo_cache_path (STRING, default .echo-curator) - where the memory lives.
• Outputs: context (STRING) and retrieval_log (STRING).

What you actually want instead

If you need prompt-context injection in ComfyUI today, you don't need a memory tier at all - you need text plumbing. Build your context string with a text-concat node (or a wildcard/prompt pack) and feed it into your conditioning. If you're doing LLM-assisted prompting, the many LLM/captioner node packs handle "remember what this project is about" in ways that actually read and write state. This node is worth revisiting if the author ships the retrieval half - the tier ordering is a clean spec - but as of v1.1.0 it's an empty shell.

Install

Same as the rest of the pack - ComfyUI Manager (search comfyui-deterministic-nodes) or:

cd ComfyUI/custom_nodes
git clone https://github.com/joe002/comfyui-deterministic-nodes

Restart ComfyUI. No models, no dependencies beyond torch>=2.0. Nodes appear under JI/Reproducible. Install is the easy part; remembering is the part that's still on the roadmap.