MiniMax-H3 LoRA Triggers

There's a specific frustration this node exists to kill. You have a LoRA that only fires when its trigger token is in the prompt - ohwx face, neon glow, whatever the trainer prefixed the captions with. You run your idea through the writer or rewriter that ships in this same pack, and out comes a beautiful structured MiniMax-H3 description. The trigger word is gone, the adapter did nothing, and nothing told you.

It's the oldest LoRA problem in a new hat. The usual fixes for it are organisational - name the LoRA after its trigger, keep a text file, let rgthree's Power Lora Loader read the words off the file. MiniMax-H3 LoRA Triggers is that habit rebuilt for a pipeline where the prompt is written by a model. The list lives on the node, with the workflow, and the words go back into a finished prompt before it reaches the sampler.

That matters because this is the one step you can't regenerate. A trigger word is a key, not prose, and nothing about a scene gives a language model a reason to keep the token ohwx. One honest limit up front: nothing is read out of your LoRA files. Of forty-four adapters on the machine this was written on, one carried a trigger_word and one an empty trigger_words - the metadata everyone assumes is there mostly isn't, and where it is, there's room for one word while the adapter may answer to three.

How it inserts them

prompt comes out character for character as it went in, apart from the words added. Nothing is re-wrapped, re-labelled or rebuilt from parsed fields. Each row is one adapter: a tick, a name for your own use, the words, and a placement. Commas split a row into separate triggers, checked and added one at a time, so a row is never half-duplicated.

The rule that matters: presence, never removal. A word already in the text isn't added again - matched on word boundaries, case-insensitively, so man isn't found inside woman. Unticking a row stops it being added; it does not take it back out. The Effect Embeddings node can remove its own tokens because it knows all ten by name; your words are somebody else's, and a trigger spelled detail cutting itself out of a sentence would eat the prose around it. So running the same text through twice changes nothing, which is what makes this safe at the tail of a graph you re-run constantly.

The inputs and outputs that matter

prompt is the text to modify - a writer's output, a reducer's, a file, something typed. bypass hands it straight through untouched. triggers is the list, saved with the workflow, and the placement marks are the part to learn:

• start of the description - the default, usually right. It opens integrated_multimodal_description after the label and in front of the prose: the field the writers put the scene in, the field everything downstream reads, and the position a caption-prefix trigger was trained in.
• start of the soundscape and start of the music do the same for those two fields.
• top of the prompt and end of the prompt are positions, not fields, so they work on text with no labels at all.

Row order isn't decoration - rows sharing a placement go in in list order. And unlike the effect embeddings, ordinary words don't flatten the blank lines below them, so top of the prompt is safe here.

Of the outputs, prompt is the modified text. added is what this run actually put in, empty on a second pass (normal) - wire it into a preview to see at a glance whether your adapter is going to hear anything. findings is what the node noticed, one line each.

Install

Same as the rest of the pack - search the registry in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/pytraveler/MiniMax-H3-Prompt-Rewriter-ComfyUI
python -m pip install -r MiniMax-H3-Prompt-Rewriter-ComfyUI/requirements.txt

Those requirements - transformers, peft, accelerate, safetensors, bitsandbytes off macOS - are for the pack's model-loading nodes; this one loads nothing and downloads nothing. You do want a recent ComfyUI, though: the pack targets the v3 node API, and on an older install nodes go missing rather than erroring.

Where it bites

Put it last - after the reducer and after MiniMax-H3 Prompt Check. The check counts words against a ceiling, so lengthening the text after it's measured is fine; before is arguing with the measurement. Anything rewriting your prompt downstream drops the words again, which is the failure you installed the node to fix.

Don't use Ctrl+B. ComfyUI's bypass stands an input in for each output by type, and there are three outputs here fed by one socket. Measured on this node: findings is handed the whole prompt as though it were a finding, and added loses its link entirely, leaving whatever it fed with no input. Nothing is reported. Use the bypass widget or the badge in the title bar.

A placement with no home falls back to the top, and findings says so - the field set differs by task (three for T2VA, six for Ref2VA) and the node only ever sees a text, which doesn't declare which task wrote it. A field reading N/A gets its own note, and the words still go in.

Know which LoRAs this helps. Only ones trained with a trigger in the caption prefix. Sliders and turbo accelerators work by weight and need no word, and on most machines those are the majority of what's installed.

From the API, triggers takes the JSON array of {name, words, where, on} objects the interface writes - or, more simply, a plain array of strings, which reads as a list of trigger words.