Lazy-refmod-split

This node exists for one reason: stacking two or three character LoRAs on a single MiniMax H3 graph makes their faces and outfits bleed into each other. It's the same multi-subject identity mush you see everywhere in image and video gen - when two characters are on screen, the model starts swapping who wears what. H3's native RefMod reference-image path keeps each identity separate, and Lazy-refmod-split is the adapter that gets them there.

It's part of the Vsaan212-workflow-utilities pack (menu: vsaan212/automation), and on its own it does almost nothing. Its whole job is fanning out one string. Understand that and it stops being mysterious.

The problem it solves

The pack's big automation node, Lazy-subject-and-scene-automation, lets you define up to three subjects in .txt files, each with a [Refmod] tag naming a character's RefMod. But instead of growing eight extra output sockets, it glues all three identities into one refmod output - a multiline "blob" that looks like this:

[Refmod1][1.0][1]
vanellope_example
[Refmod2][0.85][2]
other_character

That blob is meant for ComfyUI-MiniMaxH3Mod by Luisacaotica, whose Load H3 RefMods node takes separate mod_#, strength_#, and copies_# inputs per character. Something has to split the blob into those slots. That something is this node - the pack's README is upfront that it only unpacks names, strengths, and copies; the actual RefMod machinery is all upstream.

What goes in and out

One input, honestly. refmod is a STRING (multiline, force-input) - wire it straight from the automation node's refmod output. Empty is fine; you get all-(none) slots.

Out the other side come nine values, three per character slot:

• mod_1 / mod_2 / mod_3 (COMBO) - the RefMod name for Load H3 RefMods' dropdown, or (none) when that subject had no [Refmod]. Empty slots emit strength 1.0 and copies 1, so unused loader rows just sit inert.
• strength_1..3 (FLOAT) - from the [Refmod][strength][copies] header, default 1.0.
• copies_1..3 (INT) - the third bracket, clamped to 1–10.

One sneaky detail: the mod_# outputs are a COMBO-flavored wildcard type (same trick as CR String To Combo) so they actually link into Load H3 RefMods' dropdown sockets, which are lists of names rather than plain "COMBO" strings. A plain string type would fail prompt validation there.

Wiring it up

On the automation node set multisubject_refmod to 1, 2, or 3 and make sure each subject file carries a [Refmod] tag. Then:

1. SAS refmod → this node refmod
2. mod_# / strength_# / copies_# → the matching rows on Load H3 RefMods
3. Loader mods → Apply H3 RefMod as usual

The one trap worth flagging: on Load H3 RefMods, convert only the rows you actually use to inputs. Leave unused rows as plain widgets sitting on (none).

The gotcha: 'None' not found in mods/

This is where people get burned, and it's a genuine ordering problem. Load H3 RefMods validates its inputs at queue time - before the automation node or this split node have run. So a linked mod_# input is still Python None, which the loader stringifies to 'None' and rejects.

You do not need to fork Luisacaotica's pack to fix it. This pack wraps that loader's VALIDATE_INPUTS so unresolved or empty names are treated as (none) until the graph actually runs, at which point the real dropdown name lands. Restart ComfyUI after updating for the wrap to apply; if MiniMaxH3Mod isn't installed, the wrap is a harmless no-op.

Installing

ComfyUI Manager: search vsaan212/Vsaan212-workflow-utilities and install. Or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/vsaan212/Vsaan212-workflow-utilities

Then restart ComfyUI. You'll also need the companion ComfyUI-MiniMaxH3Mod pack for the loader and apply nodes - this node is a passenger on top of that stack. No model downloads here, and this particular node ships with zero Python dependencies beyond the standard library; the heavy transformers/qwen-vl-utils stuff in the pack's requirements.txt belongs to the LazyPrompt nodes, not this one.