VRS Folder Memory (Latest Completed)

If you've built a personal reference memory out of your own image folders, this node is the read end of it. Add it after the first folder batch finishes and it hands you the newest searchable version of that memory, every time you run - no hash-fiddling, no manually copying snapshot IDs.

What it is, in context

The pack (RS-Seasonal-Prompt-Generator) has a whole VRS subsystem - "visual reference search" - whose job is to answer one question: given this new reference image, what tags and names did my own past images suggest? You build a memory once from folders of images with embedded prompts and tags, then query it by image. Nothing is trained. It's an exact neighbor search over a vector store, and the tags of the winning neighbors become candidate material for the prompt.

VRS Folder Memory is the convenience end of that: it's the loader that points at whatever the VRS Folders panel most recently finished publishing. The other loader, VRS Native Memory Loader, wants an exact 64-character snapshot hash. That one is for reproducing an old run. This one is for living with a folder that keeps growing.

How it works

You pick a collection_id - the dropdown is populated from the collections the VRS Folders panel has registered on the server. That's it. That's the only input.

The clever bit is the IS_CHANGED implementation. ComfyUI asks a node whether its inputs changed before deciding to re-execute it, and this node answers with search_snapshot() - the hash of the newest snapshot that has finished being prepared for search. So the queue naturally re-runs your graph when a new searchable version exists, and doesn't when it doesn't.

That pairs with the panel's publishing policy, which separates "experience saved" from "search ready". Vectors get written to a checkpoint as they're encoded, and a new snapshot is published on accumulated image count, elapsed time, completion, or a clean stop. Preparing the search cache for that snapshot is CPU work that happens when the queue is idle, and it yields to your generation at every boundary. While preparation is running, this node keeps handing you the previous ready snapshot - it does not hand you a half-built one. That's the design point: your workflow never reads a memory that isn't finished.

Then the output. memory is the typed connection that goes into VRS Native Recall's memory input. snapshot is the 64-character hash, displayed as a string - save it if you care about reproducing this exact result later. And report is JSON containing collection_id, the snapshot you got, the latest_snapshot the panel has, an awaiting_search flag telling you whether a newer one is still being prepared, and store_path.

That store_path is the bridge between the two loaders: paste it and the snapshot hash into VRS Native Memory Loader and you've pinned the run exactly. Same pattern as pinning a seed, except the thing that moves is your dataset.

Wiring it up

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

Three rules that will otherwise cost you an afternoon:

1. Same vision encoder as the build. Recall checks the encoder's contract against the memory's manifest and refuses with Incompatible VRS encoder if they differ. Use the same file in VRS Native Vision Loader that you selected in the folder panel.
2. Include u in Recall's ratings if you're indexing generated images. u means unrated - it's what your own ComfyUI output gets, and a default filter that excludes it will make your folder look empty for no obvious reason.
3. Old memories don't mix. Legacy PIL/NF4 vectors from the CLI path are not compatible with the native store, and relabelling them is not a fix. Re-encode originals into a separate native memory.

Install

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

Restart after your queue is idle - the author's emphasis, because swapping model files mid-queue is a bad time. The native VRS path adds no pip dependencies at all: no llama.cpp, no separate server, no Transformers, no bitsandbytes, no torch swap. What it needs is CUDA (there is no CPU fallback for the vision encode) and a ComfyUI new enough to have Gemma 4 vision support.

The prerequisite people actually miss: models/text_encoders/ must hold an unquantized native Gemma 4 E2B safetensors with vision_model.* weights. Only the vision tensors get loaded, in FP16 - roughly 319 MiB - while the language side stays on disk. If you only followed the Q4 GGUF instructions for the prompt nodes, you don't have this file yet, and the panel won't download it for you.

Where it bites

Empty dropdown. collection_id is filled from prompt/VRS collections registered by the folder service. Fresh install, no collections → the widget shows a single placeholder string like Create a collection in VRS Folders. If you're staring at that, you haven't created a memory in the panel yet. In some setups the widget is also cached at build time, so a brand-new collection may need a browser refresh or a ComfyUI restart before it appears.

"No completed folder batch yet." The node raises this when the collection exists but no snapshot has finished. Either the first batch hasn't completed, or it errored, or you stopped it before anything was published. Check the panel's state, then Start / Resume. It does not resume itself.

Restarting the loader doesn't make indexing continue. Data collection only runs when the panel's service is active. This node reads; it never scans.

Disk grows forever. Every published snapshot keeps its objects, so a folder you keep adding to will keep consuming space, and there's no automatic pruning. Back up by copying the whole memory folder while collection is stopped; treat it as private - prompts, tags and paths survive even though pixels don't.