Fast-RH LoRA Stack

Load LoRAs on a workflow that runs on someone else's GPU. That's the pitch, and it's a bigger deal than it sounds: LoRA is how this entire ecosystem personalises a base model - a 10–200 MB patch that adds a character, style or concept without a full fine-tune - and on a hosted workflow like RunningHub your choice of LoRA was previously baked into whatever the uploader picked.

Fast-RH LoRA Stack is a stack of up to 16 LoRAs that gets applied to the remote workflow's Load LoRA nodes at run time. Same trick as the rest of the pack: it doesn't load anything locally, it sends overrides. This is the most involved node of the five by a distance - it has a model browser and a login - so budget a few minutes for setup the first time.

The prep work on the RunningHub side

Before any of this works, the remote workflow needs a Load LoRA node to receive the override. Open it in RunningHub's editor, pick any model, and set strength_model to 0. That node is now your hook. One per LoRA entry you plan to drive - up to 16 - and you need each one's node ID.

That placeholder step trips people up because it feels like it should be unnecessary. It isn't: the override writes into a node that already exists, so if the workflow has no Load LoRA node, there's nothing to write into.

How the override is built

The node's node-contract is unusually sparse for what it does: one required configs_json string, one optional previousNodeInfoList, one output. The UI is doing the heavy lifting.

configs_json holds a JSON array of entries, each with a slot name, the model filename, the remote nodeId, an enabled flag, strength_model, strength_clip, and include_strength_clip. The node's own frontend renders that as a row-per-LoRA panel with the model picker and the number fields; you're editing JSON, you just don't see it. If you ever hand-edit it, the limits are real: 1–16 entries, slot names unique, every enabled entry needs a non-empty model and a nodeId between 1 and 2147483647, strengths within ±100.

For each enabled row it emits records into the nodeInfoList: lora_name, strength_model, and - only if include_strength_clip is on - strength_clip. Those go to the RH Execute Workflow node's nodeInfoList input, or chain through previousNodeInfoList if you're already using another parameter node. Disabled rows emit nothing at all, which is how you keep one node holding several candidate LoRAs and toggle between them.

That include_strength_clip switch exists because Load LoRA doesn't always expose a strength_clip input. Send it to a remote loader that doesn't have one and the request errors. If the remote node has it, turn the switch on and set the value; if you're not sure, leave it off.

Picking a LoRA from the browser

Click "Click to choose a LoRA model…" and the node opens a browser over RunningHub's own catalogue. That catalogue is fetched with your website login, not your API key - the pack's code says so plainly, and it's why there's a separate login panel bolted onto this node.

Open Login Settings, pick the RunningHub site you're signed in to (.ai or .cn - they're distinct), paste Rh-Accesstoken from your browser's dev-tools cookies, and save. A full cookie string or a Bearer token also works; the code picks the token out of it. Browse by category or search, choose a version, and click the version's cover to drop its filename into the row.

Two housekeeping buttons matter here. Model lists are cached for 24 hours, so a LoRA you just published might not appear - Refresh List re-fetches the current page and Clear List Cache wipes the cache. And your Rh-Accesstoken is a JWT with an expiry; when it lapses, sign in again and paste a fresh one.

Install

ComfyUI Manager (search "ComfyUI Fast-RH") or:

cd ComfyUI/custom_nodes
git clone https://github.com/mikolls/ComfyUI-Fast-RH

Restart, then hard-refresh the browser - this node is mostly frontend, and a cached UI means no picker. Dependency list: aiohttp>=3.8, nothing else. No torch pin, no model downloads. You still need the official ComfyUI_RH_APICall nodes, and note the official RunningHub packs are the ones with a reputation for force-installing old numpy/transformers and breaking unrelated nodes; this companion pack is deliberately not that.

Where people get burned

Empty or expired login gives you an empty model list, not a red error. If the browser shows nothing, assume the token first.

The LoRA has to exist on RunningHub. You're naming a file in their cloud, not on your disk. A local LoRA with the same name won't be found; upload it to your RunningHub account or use a public one.

Strengths are not free-form feel. The accepted range is ±100, but that's the guard rail, not advice. Multiple LoRAs stack and interact - style plus character plus concept - and the old "0.5–0.8" folk wisdom is SDXL-lineage advice that doesn't transfer to every architecture. Start at 1.0, move one entry at a time.

A stale remote node ID applies your LoRA somewhere unexpected. Same runtime hazard as the rest of the pack: edit the remote workflow and the IDs move.