Load Anima LoRA on 3.8B (Model Only)

Anima 3.8B just landed, and the first question anyone with a folder of Base or 2.9B LoRAs asks is "do my LoRAs survive?" With a stock LoraLoader the answer is no - or worse, it's a silent yes that patches the wrong layer. Load Anima LoRA on 3.8B (Model Only) exists to fix exactly that: it takes LoRAs trained for the 28-block Anima Base or the 40-block Anima 2.9B and remaps them onto the layers those blocks actually inherited in the 52-block 3.8B, then hands the result to ComfyUI's standard patcher. One node, and your whole LoRA library carries over.

Why the plain loader breaks

Anima 3.8B wasn't trained from scratch. It grew through two interleaved layer expansions:

Anima Base: 28 blocks -> Anima 2.9B: 40 blocks -> Anima 3.8B: 52 blocks

Each step inserted 12 new blocks at fixed positions. The catch: ComfyUI's normal LoRA loader matches block numbers directly. A Base LoRA key like diffusion_model.blocks.2 isn't block 2 in the expanded model anymore - the inserts pushed the real layers around, so a naive load patches the wrong weights with no error to tell you about it. You get an image that looks subtly off, or the checkpoint just refuses to behave.

How the bridge actually works

The node counts the highest block index in the LoRA file and auto-detects whether it's a 28, 40, or 52-block layout. Then it threads every source block through both insertion maps (Base→2.9B, then 2.9B→3.8B) to find its true destination, rewrites the keys, and calls ComfyUI's own load_lora_for_models to do the actual patching. No custom patcher, no experimental switches - it's pure, verified key routing.

That verification is the part worth trusting: the author compared the official Anima Base v1.0 and 3.8B checkpoints, and all 560 tensors in the 28 inherited DiT blocks are bit-identical at their mapped destinations. The 24 expansion blocks are never touched, and native 52-block LoRAs pass through unchanged. The safe behavior is fixed on purpose; there's nothing to misconfigure.

The inputs and output you'll touch

• model - wire in the 3.8B MODEL from your UNETLoader. The node checks it's actually a 52-block model and refuses otherwise.
• lora_name - the dropdown of .safetensors files in ComfyUI/models/loras. Standard Anima Base or 2.9B LoRAs, whether they use ComfyUI-style or Kohya-style keys, both remap fine.
• strength_model - the usual LoRA strength, default 1.0. Set it to 0 and the node short-circuits and hands your model back untouched.

Output is a single MODEL. Wire it into the KSampler and anywhere else the workflow reads the model to build conditioning. In the Qwen3.5 unified-prompt workflow you connect this same output to both the sampler and the Unified Prompt node.

Install

From ComfyUI/custom_nodes:

git clone https://github.com/Lakeside529/ComfyUI-Anima-3.8B-LoRA-Bridge.git

Restart ComfyUI, done. The pack has no Python dependencies at all - no requirements.txt, no hidden install step. ComfyUI Manager will also find it if you search "Anima 3.8B LoRA Bridge". You still need the Anima 3.8B checkpoint itself (lylogummy/Anima-3.8B on Hugging Face); the node doesn't ship model files.

Gotchas, grounded in the actual code

• "requires a 52-block MODEL" means you wired in the wrong checkpoint - the 2B Base or 2.9B, say. This node only speaks to 3.8B.
• "no supported Anima DiT block keys" means the file isn't an Anima DiT LoRA at all. An Illustrious or SDXL LoRA has the wrong key format and gets rejected by design, which beats silently corrupting your output.
• If a LoRA "does nothing," confirm the source layout matches - a native 52-block LoRA loads as-is, and a Base LoRA with its blocks.2 remapped to block 4 should show a visible effect at strength 1.0.

This pack is brand new (August 2026), so there's no mountain of forum troubleshooting to lean on yet. If a file misbehaves, file an issue on the repo - the author clearly cares about the mapping being correct. For the 95% of Anima LoRAs that are style, character, Turbo, or RL model-only files, this is the one you reach for. Its CLIP-carrying sibling is only needed when a LoRA ships text-encoder weights too.