Load Model - Smart

This is the standard Load Checkpoint node plus one extra output: a trigger. That trigger is a per-model key that the pack's Smart Prompt and Smart Negative features use to remember "these saved prompts belong to this checkpoint." Load your model here instead of the core loader, and the rest of the smart system has something to hang onto.

Why you'd reach for it

The trigger output is the whole reason it exists. If you've ever saved a negative prompt that works great on one model and ruins every other model you try it on, you've felt the problem this solves. By keying saved configs to the exact checkpoint, the smart system stops you from loading the wrong prompt on the wrong model. And since it's a faithful checkpoint loader otherwise, swapping it in costs you nothing - you get MODEL, CLIP, and VAE exactly as you'd expect, plus the trigger.

How it works

It loads the checkpoint the normal way (load_checkpoint_guess_config - the same path core ComfyUI uses, including your embeddings folder). Then it builds the trigger as a hash of the model's filename plus the filename itself. When you save a prompt or negative config, that hash is what files it under in the JSON config store; when you load one later, the smart nodes look up the hash to find the matching saved text.

Inputs and outputs

• ckpt_name - the checkpoint dropdown. That's it.

Outputs: MODEL, CLIP, VAE - and trigger (a SMART_TRIGGER string). Feed the trigger into the pack's Save Smart Negative Config / Save Smart Prompt Config nodes, or into the CLIPTextEncode - Smart Negative / - Smart Prompt loaders that the pack also ships.

Installing it

Part of "quadmoon's ComfyUI nodes". ComfyUI Manager: search the pack title or Install via GIT URL with https://github.com/traugdor/ComfyUI-quadMoons-nodes.git. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/traugdor/ComfyUI-quadMoons-nodes.git

Restart ComfyUI. No extra model downloads - the checkpoints in the dropdown are the ones already in your models/checkpoints folder.

Common issues

The one trap is baked into the design, and the author calls it out in the code: the trigger is a hash of the filename. Rename the checkpoint file and the hash changes, so every prompt/negative config you saved for that model becomes invisible until you re-save under the new name. It's a clean system as long as you never rename your model files. Also remember this is a checkpoint loader, not a "smart" anything by itself - the trigger only becomes useful once you wire it into the save/load nodes that understand it.