Anima LoRA Tag Loader Extended (Experimental)

This is the experimental sibling of Anima LoRA Tag Loader (Auto Remap) - same <lora:name:weight> tag syntax, same automatic block-index remapping so old 28-block Anima LoRAs land correctly on Anima-2.9B's 40-block layout. The one new knob is blend_ratio, and it exists for a very specific nitpick: how the LoRA's effect gets projected onto the 12 newly-inserted blocks.

Here's the background. Anima-2.9B didn't retrain the new blocks - it spliced 12 extra layers in LLaMA-Pro-style, each one deep-copied from an existing old block at initialization. When a 28-block LoRA is applied to the model, those 12 new layers have no direct counterpart. The regular node handles this by taking the LoRA's delta from the preceding old layer and applying it to each new block (that's what extend_to_new_layers + extend_strength do). The Extended node generalizes that: it blends the preceding ("front") and following ("back") old layers at a ratio you choose.

new layer value = front layer × blend_ratio + back layer × (1 - blend_ratio)

At blend_ratio = 1.0 the back layer contributes nothing, and the README notes the result is numerically identical to the regular node (verified, not just claimed). Lower it and the following layer's influence starts mixing in.

Inputs and outputs

Everything from the regular loader is here: model (required), clip (optional), text, default_weight, weight_multiplier, auto_remap, save_remapped, extend_to_new_layers, extend_strength, manifest. The new one is:

• blend_ratio (0.0–1.0, default 1.0) - how the projected value on a new layer is built from the front vs. back neighbor.

Outputs are the same three: model, clip, and text with the LoRA tags stripped for your CLIP Text Encode. Wiring is identical to the regular loader.

One edge case worth knowing: the very first and very last inserted blocks have only one neighbor each, so blend_ratio is ignored there - the single available neighbor is always used at full strength. That's deliberate, because otherwise a blend_ratio favoring the missing side could zero out that layer's extension entirely.

The same cache trap, different filename

save_remapped behaves exactly as it does in the regular node - a cached file takes priority forever once written, so keep it OFF while you're tuning manifest / extend_to_new_layers / blend_ratio / extend_strength, then flip it on once you've settled. The Extended node writes its cache with a different suffix (_29Bremap_ext), so the two nodes' caches never collide or overwrite each other. And yes, the stop-on-mismatch behavior applies here too: a LoRA referencing more blocks than the connected model has raises an error instead of being applied partially.

Should you use it?

Honestly? Only if the regular node's projection onto the new layers isn't giving you what you want and you want to hand-tune it. The README's own framing is "purely for experimentation." The two nodes share all their other settings, so you can try this one and, at blend_ratio = 1.0, get bit-for-bit the regular node's output - a genuinely useful property for deciding whether you even need it.

Install

Same pack as everything else in ComfyUI-Anima29B-Remap: install via ComfyUI Manager (search "Anima-2.9B Remap") or:

cd ComfyUI/custom_nodes
git clone https://github.com/shin131002/ComfyUI-Anima29B-Remap.git

Restart ComfyUI and you're done - no extra dependencies, no model downloads. Note that this repo is frozen; future work moved to ComfyUI-Anima-Remap, and you shouldn't install both since they register the same node IDs. And remember, the remapped LoRA file counts as a derivative of Anima (non-commercial), though the images it produces are fine to use commercially.