RunwareAddLora
The LoRA stacker for Runware's websocket API
- STRING
RunwareAddLora is the sibling of FalAddLora, built for the other provider. It doesn't generate anything and calls no API - it's a string-builder that assembles the LoRA list RunWareAPI expects, so you can use your SDXL and SD1.5 LoRAs in cloud generations. If you've used FalAddLora in the same pack, the pattern is identical, just with Runware's JSON shape.
Here's the catch that trips people up: Runware addresses everything by CivitAI AIR IDs, not file URLs. Where FalAddLora takes a lora_url, this node takes lora_air - an AIR identifier for the LoRA on CivitAI. That's why the field is named what it is. You're telling Runware "load LoRA with this CivitAI ID at this weight," and Runware resolves the file on its end. No URLs, no uploads.
How it works
It appends {"model": lora_air, "weight": weight} to a JSON list - the key is model, not path, and the scale knob is called weight, matching Runware's API. The output is a JSON string like {"lora": [{"model": "...", "weight": 1.0}]}. Feed it into RunWareAPI's optional loras input. The optional loras input on this node lets you chain multiple RunwareAddLora nodes together to stack LoRAs, exactly like the Fal variant.
The inputs that matter
lora_air- the CivitAI AIR ID of the LoRA. This is the field you must get right; a typo means Runware can't resolve the model. Get IDs from CivitAI's model pages or Runware's docs.weight- 0.1 to 4.0, default 1.0. LoRA weight rules are the same as local: 1.0 is the standard starting point but often too strong; 0.5–0.8 is common for style LoRAs.loras(optional) - the chain input for stacking.
Single STRING output → RunWareAPI's loras.
Install
It ships with the ComfyUI-Cloud-APIs pack:
cd ComfyUI/custom_nodes
git clone https://github.com/BetaDoggo/ComfyUI-Cloud-APIs
or Manager → search "ComfyUI-Cloud-APIs", restart. This node needs no key of its own; the Runware key lives on RunWareAPI, where the actual generation happens.
Troubleshooting
- LoRA doesn't load / "model not found" - almost always a bad
lora_airID. Verify it against CivitAI or Runware's model explorer; this is the #1 failure point with this node. - LoRA loads but seems weak - check
weight. Below ~0.5 on a subtle LoRA can be nearly invisible; don't be shy about raising it. - Nothing wired, nothing happens - correct. It's a JSON builder; it only matters when RunWareAPI is attached downstream.
- FalAddLora vs RunwareAddLora - don't cross the streams. Fal's helper produces
{"path": ...}and Runware's produces{"model": ...}; each feeds its own generation node.
The pack is unmaintained, but this node is pure string manipulation - it'll work as long as Runware's JSON schema stays the same, which is the most stable thing in the whole pack.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| lora_air | STRING | — | |
| weight | FLOAT | 1.000.1–4 | — |
| lorasopt | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| STRING | STRING | — |