Anima Delta Mix Write into 2.9B / 3.8B insert slots without souping the stem. Node package - GitHub - <a target="_blank" rel="ugc" href="https://github.com/bestluner-create/Anima-Delta-Mix.git">https://github.com/bestluner-create/Anima-Delta-Mix.git</a> IMPORTANTDonors = 2B only. Never drop 2.9 / 3.8 into donor_stem / donor_gen1 / donor_gen2.CLIP = Qwen 0.6B only. Qwen 3.5 is not for this node or the baked file. This is not Remap and not a normal merge. Remap answers which address a tensor should land on when you move 28→40→52. Delta Mix answers what may be written at that address.The floor map is shared (official 2.9 inserts and the 3.8 trainable_dit_blocks). The write rule is not. <img src="https://image.civitai.com/xG1nkqKTMzGDvpLrqFT7WA/c252fd14-647c-45cf-905e-0ba25e6444fb/original=true/c252fd14-647c-45cf-905e-0ba25e6444fb.jpeg" />What we refuse We do not average two checkpoints inside one block. We do not smear a donor across the wrong indices. We do not treat “the last 12 blocks” as the shelf. The stem is the 28 inherited floors. They sit at the start of the tape and in the tail. What we do<pre><code>stem 28 inherited slots freeze (w=0) or lerp
insert official expansion insert += r · (donor[src] − kept)
gate unique skip drop the whole floor if donor ≈ stem</code></pre>src is the mapped 2B index, not “whatever sits next to it on a diagram”. An empty niche is better than the wrong floor. <img src="https://image.civitai.com/xG1nkqKTMzGDvpLrqFT7WA/e034f288-4c11-4dbc-af0f-ef4834293d4b/original=true/e034f288-4c11-4dbc-af0f-ef4834293d4b.jpeg" /> <img src="https://image.civitai.com/xG1nkqKTMzGDvpLrqFT7WA/053315bd-9fac-46cf-b7b9-7752a5126e00/original=true/053315bd-9fac-46cf-b7b9-7752a5126e00.jpeg" /> Nodes<pre><code>DeltaMix-2.9B 40 chassis 40 stem + Gen-1
DeltaMix-3.8B 52 chassis 52 stem + Gen-1 + Gen-2
Lora3.8B_only52 52 only 28/40/52 LoRA onto the stem
 Gen-2 left alone by default</code></pre>Donors are 28-block 2B files. Do not feed 2.9 or 3.8 as a donor. The chassis is already-expanded 2.9 or 3.8.On 3.8 the two shelves have different jobs: Gen-1 is crop (how it is framed), Gen-2 is surface (a trained file, not the same merge). Gen-2 unique is checked against the stem and against Gen-1. Do not put one branch on both shelves.How to run it<ul><li>Load 2.9 or 3.8 into the matching Delta Mix node.</li><li>Point the file fields at the chassis and the 2B donors on disk (low-RAM path).</li><li>Unique ON. Neighbor / spare / deep OFF unless you are experimenting.</li><li>w=0 leaves the stem as the chassis. w&gt;0 is already a different checkpoint, not “a bit more quality”.</li><li>Bake with ModelSave, not CheckpointSave.</li></ul>On 3.8, put a 28-LoRA through Lora3.8B_only52 with skip_gen2=true. Stock Load LoRA will drop 28-block indices onto the wrong floors. A starting point, not dogma:<pre><code>2.9 inject_delta unique 0.05
3.8 Gen-1 inject_delta ~0.35
 Gen-2 reset_muted_then_delta ~0.45
 unique 0.05</code></pre>How to read the log (short)<pre><code>stem_slots=… the 28 floors that are not niches
gen1=… gen2=… official inserts
unique src=[…] donor floors that passed the gate
dropped=['14:vs_stem'] duplicate — that slot is not written
spare wrote=0 spare map off, or it had nothing to do
holes=6 niches left empty — that is expected</code></pre>dropped is not a failure. It is the method. If Gen-2 logs vs_D1 on all 12, the second shelf is the same crop as Gen-1: change the donor, do not crank r.Neighbor spare / deep only show up if you turned the switch on. They are off from the factory.The point 2.9 already owns ~12 insert floors. 3.8 owns another 12. The node does not mint new billions of weights. It occupies houses that already exist, using a 2B donor, and throws away a floor that adds nothing. The stem is not turned into the average of two schools — so a 28-LoRA after the mix still lands where it would on base. Why this is not a merge<pre><code>full-DiT merge / lerp every block is soup of two files
extend_to_new_layers LoRA smeared onto inserts as well
Delta Mix soup banned in the niche
 niche gets a delta to kept
 a duplicate is dropped whole</code></pre>

Files with SHA256: 269192fc57d4719bd9ef547fb8492b461ba30e8d90081c97584c2a6242182e70