My dear droogs,
here it is — my first official custom node pack for ComfyUI (currently at v313), vibe-coded over the past few weeks with Claude.ai. The inspiration came from pixaroma.com, who built a fine pack of his own that lets you handle a lot of the prep work from graphics tools like Adobe Photoshop directly inside ComfyUI. This is the way!
My pack, however, is devoted entirely to LoRAs — implementing them and putting them to work. There are other LoRA nodes out there, like the "Power LoRA Loader" by rgthree, but that one only offers sequential stacking... So I had new merge and trim methods developed, to run many LoRAs at once even on stubborn models like WAN 2.2 — without the image falling apart on me. The keyword: multi-LoRA interference. Claude.ai casually nicknamed it "mush" along the way: AI LoRA porridge. Yeah — we don't want that...
So here and now, you get to group your LoRAs first, before they're merged into one single big model that then flows into the sampler — or samplers (HIGH/LOW)...
Why does that matter? Because different LoRAs overwrite different parts of the actual base model.
Picture a sugar-sweet goth girl posing for a photo shoot in a big-city back alley at golden hour — behind her, a concrete wall covered in graffiti; she has purple hair; she's wearing a black tank top, a black mini dress and ripped tights.
That's the prompt. But those are also the triggers that fire specific custom LoRAs: for the skin, for the hair, for the face of a celebrity like Margot Robbie (greetings to the Overlord!) — or for the clothes, for the lighting like "golden hour" or "god rays", and so on and so forth.
Current nodes merge all of this strictly in the order it was added to the list: indiscriminately, with no emphasis and no sense of what belongs together.
These custom nodes change that.
And the pack has a lot more on board — all of it created "on the fly", mid work-in-progress, born from things that annoyed me. For instance: kijai's WanVideo sampler simply can't be addressed with classic nodes anymore! There are Bridge nodes now that fix exactly that. And example workflows that show you how. There's a multi-model node that lets you handle several models at once via numbered switches. There's a set of analysis tools. And more...
Raise a Moloko Plus to that! And afterwards, a bit of the old ultraviolence!
Your humble narrator, Alex
------
Installation (node pack): ComfyUI-Manager → search "polyhedron" → Install — or: comfy node install polyhedron-lora-stack
Documentation: You'll find the full documentation over on my brand-new GitHub page: https://github.com/PolyhedronAI/ComfyUI-PolyhedronLoRAStack
Workflow requirements: ComfyUI-KJNodes, ComfyUI-Custom-Scripts — the wanvideo variants additionally need ComfyUI-WanVideoWrapper (kijai).
Description
First public workflow release, matching node pack v313 (3.13.0). Four WAN 2.2 dual-noise starter workflows: native KSampler (base + Wan2.2-Lightning v1.1 8-step preset) and WanVideoWrapper (base + Lightning accelerator). Each ships as JSON plus a PNG render with the full workflow embedded in its metadata — drag the image straight onto the ComfyUI canvas to load it.
Comments (9)
The stacker looks amazing but I got two issues:
- the UI doesn't correctly if comfyui has Modern Node Design (Nodes 2.0) active
- can't control clip strength individually from model strength
Hi there. Thanks for your feedback! <3 I sent it to claude.ai ^^; here is the answer:
Thanks a lot for the kind words and the detailed feedback — both points are confirmed and on the roadmap:
Nodes 2.0: The Stack/Engine UI is hand-drawn on the LiteGraph canvas, which the new Vue renderer ("Modern Node Design") doesn't draw — same situation as rgthree and other canvas-based packs. Workaround for now: disable Modern Node Design in Settings. Your rows/data are safe either way — only the rendering is affected, the backend works fine under both renderers. The next release will detect this and show a clear notice inside the node instead of leaving it blank.
Separate CLIP strength: Good catch — currently model and CLIP strength are linked. Per-row CLIP strength is planned as an optional column (off by default, fully backward-compatible with existing workflows). It's coming in an upcoming release.
Thanks again — feedback like this is exactly what helps prioritize.
@Polyhedron_AI Nice. Not to push or anything but is there any prediction on when that release will happen? And you talk about a roadmap, is there anywhere we can see that information?
Anyway, keep up the good work!
@bilboburner We just updated the repo — enjoy! :) Below is the official write-up from claude.ai; more details are in the documentation PDF on GitHub (section 3.13).
One honest note: I work with WAN 2.2 myself, and WAN LoRAs carry no text-encoder keys — so the CLIP strength is inert in my own workflows by design, and I couldn't visually verify its effect. The mechanics are test-covered, but you'd be the first real-world test on a model that actually uses it (SDXL, SD 1.5, FLUX, …). New feedback would be very welcome! :)
Per-row CLIP strength — every row can now carry a CLIP (text-encoder) strength decoupled from its model weight. Shift-click the weight value to set it (the cell shows the blue c line), Shift + ◀ ▶ steps it, and entering the model weight again re-links the row. Works on both the LoRA Stack and the LoRA Engine, in all merge modes. Rows you don't decouple behave exactly as before.
Modern Node Design (Nodes 2.0) — the pack now detects the new renderer reliably and shows a clear in-node notice plus a one-time toast instead of silently breaking. To be transparent: the canvas UI itself still requires the classic LiteGraph renderer (same situation as rgthree and other canvas-based packs) — but you'll never be left wondering why the panel is empty again.
@Polyhedron_AI You're awesome!!
@Polyhedron_AI I think the both weights are still being passed. It tries to use all the models at the same time, but in my case I need for the model strength to be 0 and the clip strength to be 0.x for some of the loras EDIT: Scratch this, I understood now. Had to read the documentation to understand the feature :)
@bilboburner So glad it clicked! That separate model/CLIP strength control is exactly what it's there for. Cheers, and happy stacking! <3
EDIT: Killed a silent group-order bug (stale order numbers blocking reassignment) and added a native over-limit toast to the Token Counter — please update your repo. :)
The modern Node design is bad and breaks most things.
@DaddyWolfgang Yeah, a lot of nodes haven't caught up to Nodes 2.0 yet. Just pushed v3.61.0 that fixes it on our end — the LoRA Stack nodes now run fine with Nodes 2.0 on, and they still fall back to the old style if you're on classic canvas, so your workflows don't change either way. Grab the update and you're good 👍 Cheers!