MiniMax H3 Clear Semantic Bridge Cache

A button pretending to be a node

This is the most boring node in the pack, and the one you'll only need in one specific situation - so here's that situation first.

MiniMax H3 Semantic Bridge (class SenseNovaH3DistilledBridge, display name without the SenseNova) keeps its loaded adapter in a module-level cache inside the pack. The adapter is a small MLP - roughly 5.5M parameters, about 22MB in fp32 - and it's cached so it isn't re-read from disk and re-bound on every queue. The cache is keyed by the adapter file's path and the device it was loaded onto.

The consequence: if you replace MiniMaxH3_SemanticBridge_v1.safetensors in ComfyUI/models/semantic_bridge/ with a different file that has the same name - a re-download, a newer revision, a version you edited - the running ComfyUI process keeps using the old weights. Everything looks fine. Your A/B shows no difference. You conclude the new file is a dud. It isn't; it was never loaded. That's the bug this node exists to fix, and it's a real one, because swapping an adapter by filename is exactly how people iterate.

What it does

One input, one output, no mystery:

• clear - a boolean, default on. Leave it as-is unless you want the node to report without doing anything.
• status - a STRING. With clear on you get "MiniMax H3 Semantic Bridge adapter cache cleared."; with it off, "Cache unchanged."

When it clears, it drops the pack's cached student adapter, runs a garbage collection pass, and calls torch.cuda.empty_cache(). That last part is why people assume it's a VRAM node. Be honest about the scale: you're reclaiming around 22MB of fp32 weights plus whatever allocator slack the empty-cache call releases. If you're trying to fix an out-of-memory failure during H3 sampling, this is not the node - the H3 weights and the encoder dwarf it, and the flag that matters is your memory settings, not this toggle. Restarting ComfyUI achieves exactly the same thing, at the cost of a restart.

Where it's genuinely the better tool is the tight loop: swap the adapter file, queue a workflow that includes this node, compare against the last run with the same seed. No restart, no reloading the 33B model. It's also the cheapest way to prove to yourself which file the pack is actually loading.

One thing to check before you blame it

status is a STRING output, so it needs somewhere to go. Wire it into a text-display node - whatever you keep around for showing strings - or into a downstream node that consumes it. If nothing downstream ever reads it, ComfyUI's graph validation can skip the node entirely, and a cache-clear node that never executes looks exactly like a cache that refuses to clear. That's the first thing to check, and the reason it's worth wiring the output even though you don't care about the string.

The node runs when the queue runs, not when you add it to the canvas, and it's instant - no extra sampling time, no GPU work beyond the empty-cache call.

Installing

Same pack, same steps:

cd ComfyUI/custom_nodes
git clone https://github.com/Speach1sdef178/MiniMax-H3-Semantic-Bridge
pip install -r MiniMax-H3-Semantic-Bridge/requirements.txt

The dependency is one line - safetensors. ComfyUI Manager will also find it under MiniMax H3 Semantic Bridge; all three nodes then live under the MiniMax H3/Semantic Bridge category. Because the pack imports ComfyUI's native H3 module at import time, an older ComfyUI fails to load the whole thing - if this node is missing from the menu, that's the likely cause, not anything about the cache.

You do need the adapter file in ComfyUI/models/semantic_bridge/ for the other two nodes to do anything useful, but not for this one. Clearing an empty cache is a no-op that returns the same status string, which is the correct behaviour and about as exciting as this article is going to get.