VRS Native Memory Loader

Two text boxes and an exact 64-character hash. That's the entire interface, and it exists because the alternative - quietly loading whatever the newest version of your memory is - makes every result you ever got unreproducible.

What it's for

The pack (RS-Seasonal-Prompt-Generator, by a solo Korean author with bilingual docs) lets you build a personal "reference memory" out of your own images: folders or JSONL pairs get encoded by a Gemma 4 E2B vision tower into vectors plus tags, and you later query that store with a new image to retrieve neighbor tags and names you actually used before. The build side writes immutable snapshots, each with a hash.

This loader is how you read one. You give it the store directory and the hash, and it opens that exact version - nothing newer, nothing "current", nothing that changed under you since yesterday.

The tooltip is blunt about the intent: exact 64-character snapshot hash; CURRENT is never followed implicitly. That's not a limitation to work around, it's the feature. Snapshot hashes are to a retrieval memory what seeds are to a sampler, except the thing that moves is your dataset rather than the RNG, and it moves whenever you index another batch of reference images.

How it works

store_path points at a memory directory - the memory/ folder inside a collection, or the store_path a build wrote. The node constructs a reader against that store, resolves the manifest for the snapshot you named, and hands back a VRS_MEMORY handle plus the manifest as JSON.

Two outputs, both simple:

• memory - typed connection, goes into VRS Native Recall's memory input. Nothing else accepts it.
• report - the manifest JSON: contract details, counts and the metadata the store recorded. This is your provenance record.

There's no image, no prompt, no search here. Loading is cheap and read-only; the expensive part happens when a query actually runs (the first search against a new snapshot has to verify the store and prepare a persistent FP32 array, which is slow once and then fast across restarts, with only new or changed entries converted afterwards).

Load-time validation is a real check, not a filename check. The store's contract fingerprints the vision weights, the ComfyUI Gemma implementation, preprocessing, pooling and torch/torchvision versions. A snapshot built under a different contract won't behave like the same memory, and the pack treats that as an error rather than a number that happens to have the right dimension.

Which loader, though?

This is the part that confuses people, because there are two and they look interchangeable:

• VRS Native Memory Loader (this node) - pinned. You supply the hash. Reproducible. If you publish a comparison, publish with one of these in the graph.
• VRS Folder Memory - follows the newest search-ready snapshot in a folder collection automatically, holding the previous ready version while a new one is being prepared. Convenient, and it changes over time.

The sane pattern is both: build with folders, do your day-to-day work through VRS Folder Memory, and when something produces a result you want to keep or re-check, copy the snapshot string it printed and the store path from its report into this loader. Same graph, frozen memory. Same idea as copying a seed out of a good generation.

Wiring, for completeness:

VRS Native Memory Loader.memory ────────┐
VRS Native Vision Loader.encoder ───────┤
Load Image.image ───────────────────────┤
                                        ▼
                               VRS Native Recall
                                        │ vrs_state
                                        ▼
                        Gemma Prompt Expander Native

Install

cd ComfyUI/custom_nodes
git clone https://github.com/raspie10032/RS-Seasonal-Prompt-Generator

Restart once the queue is idle, then look under prompt/VRS. The native VRS path adds zero pip dependencies - it rides on ComfyUI's own PyTorch and model management, no llama.cpp, no Transformers, no bitsandbytes, no torch replacement. You do need CUDA (the vision encode has no CPU fallback) and an unquantized native Gemma 4 E2B safetensors in models/text_encoders/ for the encoder node.

Nothing here downloads. There is no starter memory, no sample store, no bundled weights in the repository - the author is emphatic that the pack ships code, docs and fictional examples only. You bring the material and build your own.

Where it bites

A truncated hash. The field wants the full 64 characters. Copy it from the build report or the folder memory's snapshot output, not from a terminal that wrapped the line.

Wrong directory level. store_path must be the store itself, not its parent. If you're using folder collections, the store lives under <ComfyUI user dir>/rs_vrs_folders/<collection id>/memory/ - that memory leaf is the part people forget.

Typing CURRENT. It won't follow anything, by design. If you want latest, use VRS Folder Memory; if you're debugging why a query returns something different from last week, this node is how you prove it.

Legacy stores. Memories built by the old CLI path (PIL/NF4 vectors) are not interchangeable with native ones. Re-encode originals into a separate native store rather than relabelling; the contract check exists to stop you quietly mixing two incompatible vector spaces.

Don't treat retrieved names as facts. The candidates the memory returns are creative material, and the pack says so repeatedly. Keep the ones you want with keep_tags downstream, and keep the store private - prompts, tags and paths persist in it even though pixels don't.