Ino Create Lora Config

The pack's sampler system doesn't treat a LoRA as just a filename and a strength. It treats it as a card: an ID, a name, a trigger word, a base model, which file to load and from where, plus strength, weight type, and even tags and description. Ino Create Lora Config is the node that builds that card from plain fields and emits it as JSON - the "write your own recipe" counterpart to Ino Get Lora Config, which picks from the pack's built-in catalog.

It's one of the InoSamplerHelper nodes in ComfyUI-InoNodes, and it makes sense only in the context of that bigger system: config JSON drives the whole model-loading and sampling pipeline, so a complete LoRA card is a real input to real nodes.

The inputs that matter

• lora_id (int) and lora_name (string) - the identity of the LoRA. The tooltips call these "the id/name of the Model."
• trigger_word - the token you'd put in a prompt to activate the LoRA. Defaults to trigger, which is a placeholder, not a suggestion.
• base_model - what the LoRA was trained for. Defaults to flux1dev, the pack author's home turf.
• file - this is the sneaky important one. The tooltip says "it should be a json string," and it means a file download config in the pack's format (the kind Ino Create Model File Config outputs). So the card says not just "this LoRA exists" but "this is where its file lives."

The rest are optional metadata: lora_type (default person), weight_type (default fp16), trigger_words (a comma list, default trigger1,trigger2), description, tags, plus the two that actually affect generation: strength_model and strength_clip (both default 0.9, range −1 to 1).

Outputs: lora_id, lora_name, and lora_config - the assembled JSON.

How it works

It validates that file parses as JSON (a failed parse returns an error rather than a bad card), then packs everything into a dict with keys id, name, base_model, type, trigger_word, trigger_words, file, weight_type, strength_model, strength_clip, description, and tags, and serializes it. The output shape matches what Ino Get Lora Config returns from the catalog, so downstream nodes can't tell the difference between a catalog LoRA and a hand-built one.

Where it fits

Feed the lora_config into the pack's sampler-loading chain - the nodes that consume LoRA configs, or into Ino Load Sampler Models, which assembles a UNET + CLIP + VAE plus up to 4 LoRAs from configs. The strengths matter at generation time: on Flux-family models, strength_model is the one that usually does the real work, and 0.9 is a reasonable starting point, not a maximum.

Gotchas

The file field is the classic trip-up. It must be a JSON string - paste a raw dict in and you'll get "failed to parse file." The trigger_word defaults are placeholders; if you leave them, your card carries junk metadata that a prompt-builder downstream might actually use. And remember: unlike Ino Get Lora Config, this doesn't look anything up - it trusts what you type, so a wrong base_model or a file pointing at a missing model will only surface later at download or load time.

Installation

Part of ComfyUI-InoNodes:

• ComfyUI Manager: search "ComfyUI Ino Nodes", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/nobandegani/comfyui_ino_nodes && cd comfyui_ino_nodes && pip install -r requirements.txt, restart.

Python 3.10+, ComfyUI 0.18.1+ (V3 schema). No models or keys for the node itself - those come into play only if you feed the card to a downloader.