AI Horde LoRA

In local ComfyUI, adding a LoRA means a loader node pulling a .safetensors file from your models/loras folder. On the AI Horde, your machine never touches the file - a volunteer's worker does. The AI Horde LoRA node is how you tell that remote worker which adapter to fetch and apply, and the way you refer to a LoRA here is by its CivitAI ID, not a file path.

So the mental model flips: you're not loading a LoRA, you're referencing one. The node builds a LorasPayloadEntry - name, model strength, clip strength, and a flag for whether the name is a version ID - that gets bundled into the job sent to the Horde API. The worker resolves that ID, pulls the file from CivitAI, and applies it during sampling. It's the same distributed pattern as everything else in the pack: thin client, remote heavy lifting.

The inputs that matter

• lora_name - the CivitAI identifier (default 76693). This is the one that will bite you.
• model_strength (0.0–2.0) and clip_strength (0.0–2.0) - the two-knob weight split you already know from ComfyUI's LoRA loader: how hard the adapter pushes on the model weights vs. the text-encoder/CLIP path. Defaults are 1.0/1.0, so you only touch them when you're tuning a blend.
• is_version (default True) - whether lora_name is a CivitAI version ID or a plain model name. This matters more than it looks: get it backwards and the worker may fetch the wrong artifact or nothing at all.
• loras_list (optional) - an existing list to append to. This is your stacking mechanism: feed one node's output into the next's loras_list to chain several LoRAs, then run the final output into the Image Generate node's loras input.

Output is a single loras socket of type LORAS_LIST, and that's the only place it plugs in - the AI Horde Image Generate node.

Where people get burned

The node does zero validation. It packs whatever string you give it into the payload; it won't tell you if the ID doesn't exist or if the LoRA isn't downloadable. Two practical rules from how the Horde actually works:

• The ID must be a CivitAI version ID, not the model-page ID. Open the LoRA's CivitAI page, grab the version identifier, and confirm is_version is set to match.
• The LoRA has to be hosted on CivitAI (or otherwise reachable by the Horde's worker infrastructure). A local fine-tune sitting in your own models folder is invisible to the network - you can't upload it through this node. If you trained something yourself, you'd have to publish it first, which is a real limitation for people used to local-only LoRAs.

Also keep the strength ranges in mind: the node tops out at 2.0, so that 1.4-weight style LoRA you run locally is fine, but the Horde payload expects the same sane range. If your job comes back with a payload validation error, check the LoRA ID and version flag before anything else - they're the usual suspects.

Installing

With the rest of the pack: ComfyUI Manager → search "HordeAI" → install → restart, or clone https://github.com/Malte0621/hordeai-comfy into ComfyUI/custom_nodes and run pip install -r requirements.txt. The only real dependency is horde-sdk, and the node raises a clear error if it's missing. No LoRA files download locally - again, that's the point.

One honest note: with zero impressions and no real community chatter, this is a niche node for a niche workflow. But if you're running Horde jobs at all, it's the difference between "works with my favorite character LoRA" and "stock models only."