☁️BizyAir LoraLoader_Legacy

BizyAir ships two LoRA loader nodes, and the "Legacy" tag on this one tells you the actual story: this is the original loader from before BizyAir added custom LoRA hosting, and it's kept around so older workflows that reference it keep working rather than silently breaking when the pack updates. If you're building something new, reach for BizyAir Load LoRA instead; use this one specifically if you're maintaining or reproducing an older shared workflow that already has it wired in.

What sets it apart from the current loader

Functionally it's a LoRA patch node like any other: model and clip in (BizyAir's typed BIZYAIR_MODEL/BIZYAIR_CLIP sockets, not stock ComfyUI types), strength_model and strength_clip out to control how strongly the adapter applies to the diffusion weights versus the text encoder, both default to 1.0. The difference is entirely in where lora_name pulls its list from. Rather than reflecting whatever's uploaded to your own BizyAir account, this node's dropdown is populated from BizyAir's own curated catalog of hosted LoRAs, referenced by a path-style name (the schema's sample entries look like sdxl/Cute_Animals.safetensors, sdxl/watercolor_v1_sdxl_lora.safetensors, flux/meijia_flux_lora_rank16_bf16.safetensors), organized by base architecture. There's no model_version_id field here, because there's nothing to disambiguate, you're picking a fixed catalog entry, not a version of something you or someone else uploaded.

Outputs are the same, MODEL and CLIP, both BizyAir-typed, feeding into a BizyAir text encoder and sampler downstream same as the current loader.

Matching the LoRA to the base model

The naming convention in the catalog (sdxl/..., flux/...) is a genuine safety rail worth paying attention to: a LoRA is architecture-bound, an SDXL LoRA does nothing useful loaded against a Flux checkpoint, and even within the loosely-SDXL-compatible world, LoRAs trained for Pony or Illustrious-family finetunes don't reliably cross over to a vanilla SDXL base. Make sure the prefix on the lora_name you pick actually matches the base model you loaded upstream.

On strength: the old SDXL-era guidance of running LoRAs around 0.5-0.8 to avoid overcooking the effect is specifically that, SDXL-era guidance. On newer flow-matching architectures the community increasingly runs closer to 1.0 or above, since dropping strength there tends to cost likeness rather than just soften the effect. Start from whatever the specific LoRA's own notes suggest.

Installing it

Through ComfyUI Manager: search "BizyAir", install, restart. Or clone directly:

cd ComfyUI/custom_nodes && git clone https://github.com/siliconflow/BizyAir.git

Every node in this pack, this one included, needs a BizyAir/SiliconFlow API key set before it'll execute, via the "click to login" prompt on first use. Account signup runs through phone verification, and some users outside China have reported friction getting a number accepted, worth knowing before you're mid-build.

Common issues

If a workflow you loaded references this node and it errors on lora_name, the catalog can change over time, an entry that existed when the workflow was built may have been renamed, removed, or reorganized under a different architecture prefix since. Reopening the dropdown and reselecting the closest current match is usually the fix, there's no local file to go hunting for.

Beyond that, the usual pack-wide failure modes apply: a run that stalls or fails outright with no clear cause almost always comes down to the API key. And separately, if BizyAir turns up in your custom_nodes folder without you having installed it, that's a known quirk of ComfyUI Manager misresolving an unrelated missing-node error on an older shared workflow, not malware, safe to remove via the Manager if you don't want it.