H3 • LoRA

What it's for

Optional speed adapters and style adapters for H3, one per node, chained as long as you like. The pack's own starter workflows ship two of these bypassed by default - you can ignore them completely and generate with the base model, which is the right way to start.

It exists because of one specific bad habit in AI-adjacent node packs: hiding the adapter strength. This node puts the filename and the number on the front, and it doesn't guess a recipe for you.

How it works

You pass the model bundle in and get a modified bundle out. Under the hood it calls ComfyUI's native LoraLoaderModelOnly, which clones the model patcher - so the original bundle you wired in stays untouched. That detail is doing real work: fan the same H3 • Models output into a LoRA chain and a plain generate branch and the two don't contaminate each other, cached metadata included. No silent mutation of an upstream node, which is a pleasant change from some of the older H3 graphs.

Each node appends its name and strength to the bundle's LoRA list, which is why Render Image's run_info output can tell you exactly what got applied. Chain three adapters and the receipt shows all three.

The inputs that matter

models - from H3 • Models or the previous LoRA node in the chain. Chain order matters, and it's the order you wired, not a priority you set.

lora_name - the adapter file from models/loras/, defaulting to None. Here's the gotcha worth knowing: unlike the model dropdowns, this one is not filtered. It lists every file in your LoRA folder, including ones trained for checkpoints that have nothing to do with H3. Selecting an incompatible adapter doesn't get politely rejected - you'll get errors or nonsense. LoRAs for other architectures are simply not supported here.

strength_model - manual, default 1, range −20 to 20 in 0.01 steps. Two special values: None in the filename or a strength of 0 both short-circuit to a pass-through, loading nothing and changing nothing. That's a cleaner off-switch than unplugging wires, and you can leave a node in the graph at 0 without paying for the load.

The one recipe you'll actually start with: Larry's minimax_h3_turbo_v4_step600_ema at 0.38, with 20 steps in Render. Not 1.0, not 4 steps - the community still recipe differs from the model's own video guidance, and it's paired on purpose. Every adapter has its own recipe, and stacking them doesn't guarantee either one still applies cleanly. Set strengths to the numbers their authors published and change one at a time.

The output

models - the same bundle type that goes into H3 • Text to Image, H3 • Image Edit, or another H3 • LoRA. Type-compatible in both directions, no adapters needed.

Install

ComfyUI Manager → search "MiniMax H3 Image Studio", or:

cd ComfyUI/custom_nodes
git clone https://github.com/astropuzzo/ComfyUI-MiniMax-H3-Image-Studio

Restart and refresh. Needs ComfyUI 0.37.0 or newer. No extra Python dependencies. Beyond the three H3 model files (FL2VA diffusion model, Qwen3-VL encoder, H3 video VAE), you only need to drop your adapter into models/loras/ - and if the dropdown doesn't show it, that's a folder or a refresh problem, not a filter.

Both starter templates already contain two bypassed LoRA slots in the right place in the chain:

H3 • Models → LoRA 1 → LoRA 2 → Text to Image / Image Edit → Render Image

Where people get burned

The adapter did nothing. Check the node mode first - a bypassed node passes the bundle straight through, which is exactly what the starter workflows ship with. Then check the strength isn't 0 and the filename isn't None.

It's applied twice. The old turbo_lora shortcut on the Models node is still there for saved workflows, at a fixed 0.38. If you select Larry there and through a LoRA node, you get the adapter stacked on itself. Leave the Models shortcut on None when you're using a LoRA node.

Need more than two? Duplicate a LoRA node and chain it in. There's no hard-coded adapter limit, and the text encoder and VAE stay shared across the whole chain.

The recipe didn't transfer. Distilled adapters are paired with specific sampler, scheduler and step settings - this is old, boring knowledge in the LoRA world and it stays true here. A recipe that works for one adapter isn't a general "faster H3" switch. Copy what the adapter's author published, then use run_info to confirm what actually loaded.