SpicyAPI LoRA

The name is misleading, usefully so

Nothing here touches your disk. This node does not read a .safetensors, does not load it into VRAM, and doesn't care whether you have a models/Lora folder at all. What it does is package a URL and a strength into a SPICY_LORAS value, which a LoRA-capable model node sends along with the generation request; the weights get downloaded and applied on SpicyAPI's side. You're not loading a LoRA. You're telling somebody else which file to load.

Which is why the whole node is three fields and one output, and why the failure mode is always the same: a link that doesn't work without a session.

The fields

• url - a direct download link to a .safetensors file, and it must be http(s). The node rejects anything else with "The LoRA url must be an http(s) link to the weights file", so a local path or a civitai:// style reference is out. On Hugging Face that means the resolve/main/... file URL, not the repository page. On Civitai it usually means "no" - their download links frequently want a signed-in session or a token, and the tooltip is explicit that the link must open without a login.
• scale - strength from 0 to 4, in steps of 0.05. Video LoRAs, and especially distilled and control adapters, genuinely get used above 1.0, so the range above 1 isn't decoration. Start at 1 and move in visible steps.
• loras - an optional SPICY_LORAS input, i.e. the output of another SpicyAPI LoRA node. That's the stacking mechanism: chain them, and each node appends its own entry to the list. The model node enforces the real ceiling (three, on every model in this pack), so a fourth chain link is silently beyond the limit rather than a hard error you'll see here.

One small behaviour worth knowing: if url is left empty, the node doesn't append anything - it passes its chained input straight through. An empty URL is a no-op, not an error.

Output is loras, a SPICY_LORAS value. It only fits model nodes that expose a loras socket - the ones whose names end in LoRA: LTX-2 19B LoRA, MiniMax H3 LoRA, MiniMax H3 Image LoRA, Wan 2.2 LoRA and friends. You can't wire it into a plain model node, because there's no socket to wire it into.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/spicyapi-ai/comfyui-spicyapi

Restart ComfyUI, add your key under Settings > SpicyAPI (from spicyapi.ai/console/keys), restart once so the node list comes from your account. No dependencies, no weights, no GPU. The pack's own LoRA template - visible in the template browser under comfyui-spicyapi - comes ready to run with an Apache-2.0 pixel-art LoRA for Z-Image Turbo, which is the fastest way to see the wiring in a working graph.

Where it goes wrong

The weights have to match the base model. A LoRA trained against one architecture does not run on another - that's true locally and it's true here, and the request will either fail or produce mush. Check what the file was trained for before you spend a run on it.

Hosting is your problem. The file has to be reachable at the moment the task runs, by someone else's server. A link that expires, a Dropbox page that needs a click, a private repo: all fail at request time. Failed runs aren't charged unless the model's page says otherwise, but you've paid in time - and on a video node, in queue position.

Some models want keys, not URLs. The LTX 2.3 Spicy LoRA node is the odd one out in this pack: its LoRA input expects keys of its thirteen built-in weights, while this node always emits a URL. If a run there rejects your override, that's the reason, not your link.

There's a size ceiling on some endpoints. LTX-2 19B rejects LoRA files over 2 GiB. A bloated checkpoint repack is the usual culprit.

Strength is not a substitute for a good file. A weight that does nothing at 1.0 will occasionally do something at 3.0, and usually that something is burnt contrast. Fine-tuning by scale is a real technique; flogging a broken LoRA with it is not.