Anima 2.9B LoRA Remap (model)

You swapped Anima 2B for the 2.9B checkpoint, dragged your favourite style LoRA back in, and the result got worse. Not broken-exactly - weaker, off, sometimes barely there. ComfyUI printed nothing. No red text, no "lora key not loaded" warning, no explanation.

That's not a bug you can see, it's a bug you have to know about. Anima 2.9B is a depth expansion of the 28-block anima-base-v1.0 layout: twelve new transformer blocks are inserted into it to reach 40 blocks, LLaMA-Pro style. Your LoRA was trained on the 28-block base. Drop it on a 40-block model unchanged and block index 17 in the LoRA lands on block 17 of the model - which, thanks to those insertions, is simply a different functional layer. The LoRA still loads and still fires. It just fires in the wrong place.

This node is a one-socket fix for exactly that, and nothing else.

What it actually does

The pack's own source is the clearest description, so here it is straight: every standard LoRA loader ends in ModelPatcher.add_patches(patches, strength), with patch keys already resolved against the model you loaded. Fens intercepts that call, shifts the block index from the 28-block numbering into the 28 positions those blocks occupy in the 40-block model, then translates the applied keys back to their original names - so ComfyUI's own integrity check still matches and doesn't flag every renamed key as a false failure.

Two details worth knowing because they decide whether it works for you:

• It clones the patcher (model.clone()) and swaps in a subclass whose add_patches does the remap. Because clone() rebuilds patchers with the same class, the behaviour follows the model through the rest of the graph - LoRAs applied several nodes downstream still get remapped.
• The remap only triggers when the incoming patch set covers exactly blocks 0–27. That guard is what keeps the node from double-mapping an already-shifted LoRA, and it's why Flux LoRAs, SDXL LoRAs and any non-Anima model pass through untouched. Leave it in a mixed workflow; it won't eat anything.

When it fires you get one console line. When it doesn't, it tells you why - see the troubleshooting section, because that line is your only feedback.

Inputs, outputs, and the one thing you can get wrong

There are no widgets on this node. Nothing to configure, no strength, no options.

• model (MODEL, required) - wire it from your loader: Load Diffusion Model, CheckpointLoaderSimple, whatever you use.
• MODEL output - into your LoRA loader or LoRA stack (LoraLoader, rgthree's Power Lora Loader, any stacker).

Placement is the entire game. It goes after the model loader and before any LoRA loader or stacker. Put it after the LoRA node and you've done nothing at all: the patches were already applied before your remap node ever saw the model.

Anima is also unusually cheap to train LoRAs on - ~1800 steps is the community number, with overfitting after 2400–3000 - which is exactly why mismatched LoRAs are the recurring headache: they get made constantly, and version bumps are the documented failure mode. Preview 3 broke Preview 2 LoRAs. This node is the same story with the mechanism made visible.

Install

ComfyUI Manager → search Fens-Simple-Nodes → install → restart. Or:

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

Then restart ComfyUI. There is no requirements.txt in the repo, no pip step, and no model to download - the node's own header says "Loads nothing." Pure Python.

One real requirement: the pack uses ComfyUI's newer V3 node API (comfy_api.latest). If the nodes don't appear in the list after a restart, update ComfyUI before you start debugging the pack.

When it silently does nothing

Expect no news. A successful remap logs one line like:

[Anima LoRA Remap] 28-block LoRA on 40-block Anima-2.9B: remapped N target keys.

Four things go wrong, all quiet:

1. The checkpoint didn't load as 40 blocks. If the console shows model is not a 40-block Anima-2.9B; passing it through unchanged., your ComfyUI is loading the file but not the full block count. The node's docstring names the fixes: a ComfyUI build with PR #15555, or the blocksPatch shipped with the original ComfyUI-Anima-2.9B. Without that, the node has nothing to align to.
2. It's downstream of the LoRA loader. Move it up.
3. The LoRA isn't a full 28-block LoRA. The guard requires the patch set to cover all 28 base blocks; a LoRA trained with selective blocks - which style-focused diffusion-pipe configs do - falls outside it and isn't remapped. No remap line in the console = it didn't fire.
4. Wrong expectations. Remapping restores alignment; it doesn't improve a weak LoRA, and it can't help a LoRA trained on 2.9B itself rather than the 2B base. Result should read closer to what the LoRA did on 2B, not identical, since twelve blocks you never trained on are still sitting in the middle of the stack. Expect to re-tune strength.

The honest summary: this is index arithmetic that ComfyUI won't do for you and won't warn you about. One socket in, one socket out, and a log line you should actually read.