Omini Kontext LoRA Loader

The base omini-kontext pipeline can insert a generic reference, but the results that actually made people notice this project came from the fine-tunes - LoRA weights trained for specific insertion tasks, most famously the character-insertion LoRA. The Omini Kontext LoRA Loader is how you get those onto your pipeline. In the bundled example workflow it sits right between the Pipeline Loader and the main generation node, and the whole chain is loader → LoRA Loader → Pipeline.

This matters more here than in a normal Flux workflow. Kontext-era LoRA culture is a thing of its own - a stack of LoRAs is literally the reason people keep Kontext installed years later, because some of the best ones were never retrained for the newer editors. Omini-kontext rides that same train: the model's whole identity is "base Kontext + a LoRA that was trained to place characters spatially".

How it works

It's a diffusers PEFT-style load, not a ComfyUI-style model patch. The node calls pipeline.load_lora_weights(lora_path, adapter_name=...) and then pipeline.set_adapters([adapter_name], adapter_weights=[strength]) - which is why the output is a OMINI_KONTEXT_PIPELINE again, with the adapter baked in. Wire that same pipeline object downstream and the generation node picks up the LoRA automatically.

The inputs that matter

• pipeline - the pipeline from the loader (or chained from another LoRA node).
• lora_name - a dropdown that lists every .safetensors/.pt/.ckpt in ComfyUI/models/loras, plus a custom_path option for when your file lives elsewhere (like the README's example that downloads straight into models/loras). The saquiboye/omini-kontext-character LoRA is the one the workflow expects.
• strength - default 1.0, range -10 to 10. 0.5–0.8 for a subtle effect, 1.2–1.5 to push it. Negative strengths are technically accepted but you're going to get garbage; treat them as "allowed because diffusers allows it", not a feature.
• custom_lora_path (optional) - absolute path used when lora_name is set to custom_path.
• adapter_name (optional) - defaults to omini_kontext. You only need to touch this if you're loading multiple adapters and merging them later, because the merge node addresses adapters by name.

Where it slots in

The README's flow is: load the character LoRA, load your scene and reference images, connect everything to the Pipeline node. If you want to compare "with LoRA" vs "without" in one workflow, chain the LoRA Loader's pipeline output into the LoRA Unload node and generate twice - no need to reload the model between runs. And if you're combining the character LoRA with a style LoRA, you're looking for the LoRA Merge node instead; that one stacks multiple adapters by name and weight.

Gotchas

Two things bite people. First, the dropdown only shows files that existed when ComfyUI (re)started - drop a new LoRA into models/loras and it won't appear until a restart, the standard ComfyUI behavior. Second, a strength of 1.0 is the pipeline default and it's strong; if your inserted character comes out looking overcooked or the scene dissolves into it, the fix is usually backing the strength down, not swapping LoRAs. That's the same knob discipline as every other Flux LoRA workflow - start at 1.0, pull back to where the character reads right.