LoRA Prompt Loader

Let's get the elephant out of the room first: the pack's own FAQ says LoRA Prompt Loader is a legacy node and recommends you build new workflows on Model & LoRA Group Loader instead. So why is this one still worth knowing? Because it's the only loader in the pack that hands you the merged prompt as plain text - and if you like keeping your prompts visible and editable as strings, that's a real feature.

What it does

It's a combined base-model + LoRA stack loader. Pick a checkpoint (or pass a MODEL up from upstream), and it applies every LoRA in the stack while also building your final positive and negative prompts. The twist is in the outputs: along with the patched model, clip, and vae, it returns positive_text and negative_text as plain STRINGs - already merged, LoRA contributions first, your own text after, deduplicated.

That's the whole point versus its sibling. Model & LoRA Group Loader spits out raw lora_prompt_data JSON for the PromptCraft prompt node to consume. This node instead gives you text you can read, edit, pass through other text nodes, or feed straight into a CLIP encoder - the README's "Pipeline B" wires it into CLIP Text Encode Pro:

CheckpointLoader → LoraPromptLoader → CLIPTextEncodePro → KSampler

The inputs that matter

• checkpoint - dropdown of your checkpoints, or None to use the MODEL from upstream.
• strength_multiplier - a global LoRA weight multiplier (0.0–2.0, default 1.0). Turn everything down at once instead of editing each entry.
• positive_text / negative_text - your own prompt text. The LoRA prompt elements get prepended to these automatically.

The optional lora_stack_data is a hidden JSON widget the pack's frontend manages - you don't type into it; it carries the stack you assemble in the canvas widget.

How it works, mechanically

The backend parses the stack JSON, resolves group references to their concrete LoRA lists at execution time (so a group you edit in the LoRA Hub takes effect on the next run), and applies each LoRA with its per-entry model weight and clip weight, both scaled by strength_multiplier. Disabled or zero-weight entries are skipped, clip is skipped when no CLIP is connected, and loaded LoRA files sit in a thread-safe LRU cache (max 8) so repeated runs don't re-read the same weights off disk. Missing LoRA files in a group get skipped with a console warning rather than killing the run.

Why you'd still reach for it

The plain-text output is genuinely nicer to debug with. When a render comes out wrong, you can read exactly what the stack injected into your prompt instead of trusting a JSON blob. If you're building a text pipeline anyway - wildcard expanders, prompt-picker nodes, anything that expects a STRING - this node drops in without a type mismatch. Otherwise, and especially if you want the prompt-data feed for the PromptCraft node, use Model & LoRA Group Loader.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/moton16/ComfyUI-PromptCraft

or ComfyUI Manager → search ComfyUI-PromptCraft, then restart. No model downloads; the LoRAs come from your models/loras folder.

Troubleshooting

• "未提供 MODEL" ("no MODEL provided") - the error you get when checkpoint is None and nothing is wired into the optional model input. Pick a checkpoint or connect upstream.
• A LoRA in a group is skipped - check the console for the "LoRA file not found, skipping" warning; the file either moved or was renamed. The pack's scanner reads models/loras.
• Stack widget looks broken after a ComfyUI update - the canvas stack is frontend-heavy and the Nodes 2.0 rewrite has broken rendering for several packs; falling back to the legacy canvas is the standing workaround.