Anima 3.8B LoRA Remap (model)

Anima 3.8B is not a bigger training run of the 2B base. It's a stack of depth expansions: the 28-block anima-base-v1.0 layout got twelve blocks inserted to become the 40-block Anima-2.9B, and the 3.8B inserts another twelve on top of that to reach 52 blocks.

Your LoRA was trained on the 28-block base. So it is now two expansions away from where it's supposed to sit, which is why it loads happily on 3.8B and does close to nothing.

Why this node composes two steps instead of one

Here's the part worth understanding, because it's the difference between "remap" and "the right remap." The 3.8B checkpoint's own metadata describes the step it performed: expansion source Anima-2.9B, 40 blocks in, 52 blocks out, insertion positions listed. That's a mapping from 2.9B numbering to 3.8B numbering - and it is not the mapping a 2B-trained LoRA needs.

Fens' source is explicit about this, and it's the sort of thing most packs get wrong: "Both of our nodes are meant to remap LoRAs trained on the original 28-block anima-base-v1.0, regardless of which larger checkpoint they're applied to. Anima-3.8B is two expansion steps away from that base (28->40->52), so its node needs the composed 28->52 mapping, not the 40->52 mapping between 2.9B and 3.8B alone."

So the node chains the two expansions into one base-to-target table. If it used only the second step, a 2B LoRA's blocks would get remapped through positions meant for a 2.9B LoRA - a plausible-looking, still-wrong answer.

Mechanically it does the same thing as its 2.9B sibling: it clones the model's patcher, subclasses it, and rewrites block indices inside ModelPatcher.add_patches, translating the applied keys back so ComfyUI's "lora key not loaded" integrity check doesn't scream at every renamed key. It remaps only patch sets covering exactly blocks 0–27, so nothing gets double-mapped and your other LoRAs and other models pass through untouched. It's a silent node - one log line when it fires, a warning when it won't.

Which one do you install

Use exactly one, the one matching the checkpoint you loaded. Don't chain the 2.9B node into the 3.8B node as a "belt and braces" move - there's nothing to gain. Each node checks the loaded model's block count against its own target before doing anything, so a mismatched node logs model is not a 52-block Anima-3.8B; passing it through unchanged. and hands the model on. Harmless, but it means a wrong pick looks like it works. If you keep both checkpoints installed, you're expected to swap nodes when you swap models, or park both and let the logs tell you which one actually did something.

Inputs, outputs, placement

One required input, one output, no widgets:

• model (MODEL) - from your loader: Load Diffusion Model, CheckpointLoaderSimple, whatever's in your workflow.
• MODEL out - to your LoRA loader or stack (LoraLoader, Power Lora Loader, any stacker).

Slot it after the model loader and before any LoRA loader or stacker. That ordering isn't stylistic: a LoRA applied upstream of this node has already been patched into the model, and the remap never sees it. If you're wiring it right now, the check is trivial - the wire goes loader → remap → LoRA.

Install

Same pack as the 2.9B remap, so if you have one you have the other. Manager → search Fens-Simple-Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Taithrah/ComfyUI_Fens_Simple_Nodes

Restart ComfyUI. No requirements.txt, no pip installs, no model downloads - the node header is blunt about it: "MODEL in -> MODEL out. Loads nothing." It does require a ComfyUI new enough for the V3 node API (comfy_api.latest); if the nodes don't show up after restarting, update ComfyUI first.

The failure modes, briefly

• No remap line in the console means it didn't fire. Look for [Anima LoRA Remap] 28-block LoRA on 52-block Anima-3.8B: remapped N target keys.
• The warning instead of that line means your ComfyUI isn't loading the checkpoint at its full 52-block depth - the node's docstring points at ComfyUI PR #15555 or the pack's blocksPatch for the expanded Anima checkpoints. Nothing loads, nothing to align.
• A LoRA trained on 2.9B, or one trained on only a subset of blocks, isn't the target audience. The guard wants a patch set covering all 28 base blocks, so selective-block style LoRAs slip past unremapped - which is exactly the "it loaded and did nothing" symptom you probably arrived with.
• It restores alignment, it doesn't restore results. Twelve inserted blocks sit between your LoRA's layers and the ones around them, so expect it to look closer to what you got on the 2B base, not identical. Adjust strength from there.

If your LoRA is a style LoRA you trained yourself in a couple of hours on the 2B base - which is how most Anima LoRAs get made, given it's a 6GB-card-friendly model that plateaus around 1800 steps - this node is the difference between your work surviving the upgrade and quietly evaporating.