GPM VLM Prompt Loader

One dropdown, three outputs, and the least obvious node in the pack. It doesn't touch your image prompts at all. What it carries is the recipe the scanner uses to write them.

That's worth a node, if you think about what the recipe is. The scanner's system_prompt isn't a caption template - it's a strict instruction format holding the whole contract: return JSON only, two keys, comma fragments not sentences, person and scene must not overlap, enumerate 10–20 fragments and don't invent details to reach the count. The built-in SDXL preset's prompt is about 2,700 characters of that. Get it wrong and every sidecar in the folder is wrong in the same way.

What it is, mechanically

The Loader reads a preset by stable ID and emits a normalised bundle:

• preset_bundle - a GPM_VLM_PROMPT_PRESET, a dict-shaped payload with the preset's id, name, family, system_prompt, use_ban_list flag, ban list, version, and an ok status.
• status_text - a plain sentence, e.g. Loaded preset 'builtin-sdxl'.
• preset_json - the same bundle serialised, for logging or previewing.

If the preset ID doesn't resolve, the bundle comes back with ok: false and an empty prompt rather than an exception - so a downstream Saver gets a clean "can't load source" instead of a traceback.

Presets come in two flavours. Built-ins ship with the pack (SDXL, Pony, Natural Language) and are read-only templates. User presets you create with the Saver node live separately under ComfyUI/user/default/GPM/vlm_prompt_presets.json. The dropdown shows readable names, and if two presets share a name the label gets the raw ID appended so you can tell them apart. Older workflows that stored raw IDs like builtin-sdxl still resolve - the node accepts either form.

Wiring it

selected_preset (enum) → into source_preset on GPM VLM Prompt Saver. That's the intended pairing: Loader is the source selector, Saver does the mutating. The split exists so a Loader can sit inside a graph as a fixed "use this recipe" statement, while the Saver holds your edits and runs the actual save/update/delete action on queue.

It's a config bus, not a prompt path. Nothing about your generation changes because you loaded a preset here; what changes is what the VLM scanner will say next time you queue a scan with that preset selected.

When you'd actually use it

Copy-and-edit. Point the Loader at the built-in SDXL preset, feed it to the Saver, hit LOAD FROM SOURCE, then paste your own tweaks into the Saver's system_prompt field and SAVE AS NEW USER PRESET. You now have a variant with your own vocabulary in it - say, one that always names clothing materials and never mentions lighting - without retyping 2,700 characters of contract.

The other use is reproducibility. A user preset is a file on disk with a stable ID. If you're captioning a library you care about, naming the recipe and sharing it is how someone else reproduces your scan output exactly.

Install

ComfyUI Manager → Gallery Prompt Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Mystic419/GPM-for-ComfyUI GPM
cd GPM
python -m pip install -r requirements.txt
python install.py

This node is pure Python and needs no VLM to run - you can load, inspect and copy presets on a machine that will never run a scan. The install.py step (the llama-cpp-python wheel handling) and matching mmproj files only matter when you actually queue a scanner node.

Where people get burned

• What's actually in the built-in presets is not visible from the node. preset_json is the only way to eyeball a preset's contents from inside ComfyUI, so wire it to a preview or a text-show node before editing anything.
• Loading is not editing. Running the Loader changes nothing on disk. If you queued a Saver with LOAD FROM SOURCE and then closed the workflow expecting a new preset, there's no new preset - SAVE AS NEW USER PRESET is the action that writes.
• The Loader's dropdown is built once, at node-definition time. Adding a user preset elsewhere means a ComfyUI restart (or at least a workflow reload) before the new one shows up. The pack's own docs list dynamic dropdown refresh as not implemented.
• Built-ins can't be overwritten from this path. They're read-only by design; a Saver UPDATE EXISTING USER PRESET against a built-in source is refused with builtin_read_only. Clone to a user preset instead.