Saya HiDream LoRA · Settings & Trigger Prompt

What it is

A settings widget that outputs two things: a lora_config bundle for SayaHiDreamLoraLoader and a plain hidream_trigger string for SayaComfyCoupleHiDreamCopy. Four inputs, enabled, lora_name, strength_model, trigger_text. It patches nothing itself - it's the decision, not the action.

The interesting part is why the trigger lives here. Every LoRA has a magic phrase, and the standard ComfyUI move is to type that phrase into the front of your prompt and hope you remember to do it in all three of your positive prompts. With a two-character regional workflow you have Base, Person 1 and Person 2 of them. Miss one and the character on the right is subtly unstyled. So the trigger is a routed value instead: you write it once, on this node, and the HiDream COPY node prepends it to all three regional prompts before encoding.

How it behaves

active = enabled AND lora_name != "none" AND strength_model != 0. When that's true, the node emits the config and the stripped trigger text. When it isn't, it emits the config with enabled: false and an empty string for the trigger. So flipping one switch turns off both the weight patch and the injection - which is exactly what you want when you're A/B-ing whether the LoRA is helping at all.

The injection is a prepend, not a merge:

Base HiDream:     exampleStyle, <Base original>
Person 1 HiDream: exampleStyle, <Person 1 original>
Person 2 HiDream: exampleStyle, <Person 2 original>
Negative HiDream: <Negative original>

Simple comma-separated duplicates are avoided - if your prompt already contains the trigger as a standalone comma item, it's moved to the top rather than doubled, and if it's already leading the prompt nothing changes. The negative is left alone, and so are your SDXL and Naturalize prompts; the injection is a HiDream-path concern only.

There's a subtlety with the text-conditioning cache that's worth understanding before you spend an hour debugging. The cache key hashes the final injected prompt strings, so changing the trigger text correctly invalidates cached conditionings and forces a re-encode. Changing the LoRA filename or strength does not - the LoRA is a MODEL-side patch and the text hasn't moved. That's a deliberate split, and it's why you can sweep strength values without paying for a quad CLIP encode each time.

Ranges: strength_model runs from -20 to 20 in 0.05 steps, defaulting to 1.0. Negative values invert the LoRA's effect, which occasionally does something interesting and mostly does something broken. lora_name is a dropdown of whatever's in your loras folder, plus none.

Install

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/alphaziod/saya-comfy-couple-plus.git

Restart and refresh the browser. Drop your HiDream LoRAs in the usual ComfyUI/models/loras/ and they'll appear in the dropdown after a refresh. NumPy and Pillow are the only declared dependencies; the pack doesn't install PyTorch, so your ComfyUI build stays untouched. One copy only, and that includes not leaving an old comfy_saya_couple folder around - it registers the same node IDs.

Where people get burned

You set the trigger here and also typed it into your prompts. The node won't remove text you wrote by hand. Pick one source. This is also the reason disabling the panel leaves a handwritten trigger in place - it's not a bug, the node simply doesn't edit your prompt.

The trigger "isn't working" on the negative. It's never applied there. HiDream trigger injection is Base, Person 1 and Person 2, by design, so that you can put the LoRA's trigger on the positive side without also demanding it of the thing you're trying to avoid.

You expected the trigger to appear when the panel is disabled. strength_model = 0 or lora_name = none gives you enabled: false and an empty trigger string. If you want the injection without the weights, that combination won't give it to you - set a real filename and a small strength instead.

A LoRA that ships text-encoder weights. The loader is model-only, so those weights aren't applied; the trigger field is the intended stand-in. If the LoRA genuinely changes meaning with its prompt and the trigger alone isn't reproducing it, that LoRA probably wants a different loader.