Nodes/BUNNY_H3_Conditioning_Bridge/BUNNY H3 Conditioning Bridge
ComfyUI Node

BUNNY H3 Conditioning Bridge

One node to stop H3 forgetting who's holding the sword

By aa335615543-ux·Created about 24 hours ago·Updated about 18 hours ago· 2
BUNNY H3 Conditioning Bridge
  • conditioning
  • conditioning
adapter
alpha0.10
magnitude_matchper_token
enabledtrue

MiniMax H3 is great at motion and quietly bad at remembering who is doing what. Two fighters cross, one gets occluded for eight frames, and the sword changes hands. The BUNNY H3 Conditioning Bridge targets exactly that, and it's a smaller thing than its name suggests: no LoRA, no prompt rewriting. You drop it inline in an existing CONDITIONING wire and it nudges H3's text conditioning so the model keeps its cast straight.

What it actually is

A conditioning adapter in the same family as IP-Adapter or ControlNet - a module that massages the conditioning tensor before the sampler sees it - except it adds nothing new, it rewrites what you already have. The author splits the job explicitly: a combat or motion-continuity LoRA handles how the action moves; this handles who is doing it and which state belongs to whom. Hence the pitch at 1-vs-4 brawls and turn/cross/occlusion shots rather than general quality. It's the video-side cousin of the character consistency problem - the multi-character scene everyone else solved by editing frames.

How it works

The adapter is a three-layer MLP (fc1 → fc2 → fc3, SiLU on the first two) mapping 5120-dim conditioning vectors to 5120-dim vectors. The loader hard-checks that: 5120 in and out, plus weights and biases for all three layers.

Your conditioning arrives as [B, T, 5120], gets RMS-normalised, runs through the MLP, and is blended back:

hybrid = original + alpha * (projected - original)

So alpha is a lerp weight, not a LoRA-style strength. At 0.0 you get your tensor back untouched and the node short-circuits before loading anything. magnitude_match covers the other half - the MLP has no idea how loud your conditioning should be, so its output is rescaled to the original's RMS: per_token per token (direction changes, energy is kept), global across the whole tensor, none raw. Stay on per_token. It's cheap, too: the MLP runs fp16 on ComfyUI's active GPU (fp32 on CPU) and hands your tensor back at its original device and dtype.

Inputs and output

Five required fields, one output.

  • conditioning - the wire from H3's text/prompt conditioning, which must be [B,T,5120]. Anything else raises a shape error telling you to place the node after the H3 encoder.
  • adapter - a dropdown built from the safetensors it can find. NO_ADAPTER_FOUND.safetensors means you haven't installed the model yet.
  • alpha - default 0.10. The README's starting range is 0.10–0.15, and higher is not automatically better.
  • magnitude_match - per_token, global, or none. Leave it alone.
  • enabled - a true bypass: no model load, no tensor copy, no compute. Your A/B switch: same seed, toggle, compare.

The output is a single conditioning wired into whatever the original cable fed. The node stamps bunny_h3_bridge, its alpha, mode and adapter name into the conditioning metadata, so a run that looks the same still tells you whether the bridge fired. Placement is the whole game: after H3's text-conditioning encoder, before the original downstream node. Unplug the CONDITIONING cable, insert the bridge, reconnect. It isn't a model patch - don't try it on MODEL or LATENT lines.

Installing it

ComfyUI Manager, search BUNNY_H3_Conditioning_Bridge (the manifest name is bunny-h3-semantic-bridge, so the folder may land under that - the node doesn't care). By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/aa335615543-ux/BUNNY_H3_Conditioning_Bridge

requirements.txt is one line: safetensors. If you can run H3 at all, you can run this. Restart ComfyUI.

Then the model, the step people miss. The pack ships an empty models/ folder, so grab the adapter from JOKER141/BUNNY_H3_Conditioning_Bridge and drop it in either:

ComfyUI/custom_nodes/BUNNY_H3_Conditioning_Bridge/models/
ComfyUI/models/semantic_bridge/     # legacy external folder, still supported

Naming drifted between releases - the README says BUNNY_H3_ActionLogic_Bridge_V1.safetensors, the repo's own note points at the current BUNNY_H3_SelectiveCrossLayer_ActionLogic_V1.safetensors. Both still load.

Fit, and where it doesn't

The author's own numbers, which almost nobody publishes: about 60% of his test cases showed repair, 20% looked identical with the bridge on or off, and 10% produced new errors. Observations, not a benchmark - but take the 10% seriously. This is a gentle intervention, not a fix. One thing worth knowing before building on H3 at all: its licence excludes the US, EU, UK and South Korea from the grant, outputs included.

Troubleshooting

Dropdown says NO_ADAPTER_FOUND.safetensors, or queueing throws "adapter not found." The node searches the pack's own models/ folder first, recursively, then ComfyUI/models/semantic_bridge/. Put the safetensors there and refresh the frontend - the adapter list is built when the node's inputs are defined, not on every queue.

"Expected MiniMax H3 CONDITIONING [B,T,5120]". You're feeding it conditioning from something other than H3's text encoder. The same check is why adapters built for other models won't load: you get a dimensions error, or a missing fc1/fc2/fc3 complaint, instead of silent garbage.

It made things worse. Lower alpha - try 0.05 and 0.10 on the same seed rather than pushing toward 1.0 - and confirm magnitude_match is still per_token.

CategoryBUNNY/MiniMax H3

Inputs (5)

NameTypeDefaultDescription
conditioningCONDITIONING
adapterCOMBO1 options: NO_ADAPTER_FOUND.safetensors
alphaFLOAT0.100–1
magnitude_matchCOMBOper_token3 options: per_token, global, none
enabledBOOLEANtrue

Outputs (1)

NameTypeDescription
conditioningCONDITIONING