WAN LoRA High/Low Splitter

Wan 2.2 isn't one model, and that's the whole reason this node exists. It runs two passes: a high-noise pass that handles motion and scene composition, then a low-noise pass that polishes detail. A LoRA trained for one pass can fight the other, which is why the community trains HIGH/LOW pairs - or HN/LN variants, or _H/_L - and applies each half to its own pass. That means your graph needs two separate prompt strings, each carrying only its pass's LoRA tags, and doing that by hand with a dozen tags whose names differ by one word is exactly the kind of task you'll get wrong once. The WAN LoRA High/Low Splitter splits a prompt into those two variants for you.

Mechanically it's a regex + local-LLM pipeline. It extracts every <lora:...> tag from prompt_text, sends the list to a local Ollama model - qwen2.5-coder:7b by default - with a system prompt that teaches the HIGH/LOW/HN/LN/H/L naming conventions and asks for a JSON classification. If the model isn't installed, the node checks Ollama's /api/tags and pulls it automatically. Then it strips all tags out of the original prompt to get the base text, and builds:

• high_prompt - base prompt + the HIGH-tagged LoRAs, for the high-noise pass
• low_prompt - base prompt + the LOW-tagged LoRAs, for the low-noise pass
• analysis - a JSON dump with each tag's strength and relative model path, so you can check its work

One input (prompt_text, multiline), three string outputs. In a real Wan 2.2 workflow you'd feed high_prompt into the high-noise model's text encode and low_prompt into the low-noise one.

This is the one node in the pack with a genuinely heavy external requirement: you need Ollama running at localhost:11434, and the default model pull is around 4.7 GB. The README's dependency table only calls out Ollama for the separate Prompt Splitter node, but this one uses it too - the code is unambiguous about that. If Ollama isn't installed, the node queues and fails at classification time rather than telling you nicely, so check that first.

Where I'd flag a real gotcha: the input tooltip promises that single LoRAs (tags with no HIGH/LOW marker) are included in both prompts. The shipped code doesn't do that - it only keeps the high_tags and low_tags buckets from the LLM's JSON, so an unpaired tag like <lora:detail:0.8> silently disappears from both outputs. If you're mixing plain LoRAs into a two-pass prompt, keep them out of prompt_text and add them back yourself, or check the analysis output and be unpleasantly surprised later. The README-and-source mismatch here is a small lie with a real consequence.

Also worth knowing: this is classification, not semantic judgment. The LLM is making a call about tag names based on patterns, and it's a 7B model doing it - the naming conventions it was trained on (HN/LN, _H/_L, High/Low casing) are all in the system prompt, but the first time you run it, actually read the analysis output. It'll be right most of the time, and when it's not, you'll want to have caught it before the render.

Install is the pack standard - ComfyUI Manager, search "LoRA Visualizer", restart, or clone into custom_nodes. No Python extras beyond what the pack ships; Ollama itself is the real install step.