Mojo Loader

Mojo Loader is the read side of the .mojo format: it opens a file saved by Save Mojo and reconstructs the generation - the latent, the conditioning, the masks - so you can refine or upscale it without re-typing a single prompt. Where it gets interesting is that the conditioning isn't stored as text, it's stored as encoded tokens per text encoder. That means the loader re-encodes those tokens with whatever clip you feed it today, not the one from when the file was made. Same prompt, different model, zero re-typing. That's the whole mojo trick.

The inputs that matter

• Main_clip - the clip to re-encode the stored tokens with. It's mandatory, and it's the key to the whole thing: the loader reads which encoder signatures the mojo contains, maps the tokens onto whatever your clip provides, and skips what doesn't match.
• Output_Path - subfolder under output/ where the .mojo lives, default Hellkars/Mojos (matches Save Mojo's default).
• Name - the file name, minus .mojo (default "ShareMy").
• Clip_Choice - Main, Additional or Special. The mojo can hold tokens from up to three clip sources (Main, Alternative, Special from Mojo Maker). This biases assembly toward one of them when more than one is present.
• Conditioning_Output - Disabled (no conditioning, just latent + masks) or Mojo (Combine) (rebuild combined positive/negative conditioning from the stored tokens). The second is the default and what you'll almost always want.

Outputs

• Latents - the stored latent, wire it to a VAE decode to see the image as saved, or into a sampler to refine it further.
• Positive / Negative - the rebuilt CONDITIONING, ready for a KSampler.
• Positive_Mojo / Negative_Mojo - the raw Mojo flows, pass-through for chaining into Adjust Mojo.
• Info - a string with what the file says about itself: the settings you recorded at save time, which encoders matched your clip, and the mojo's iteration number.
• Positive_Masks / Negative_Masks - the masks stored with the conditioning, if any.

How it works

The loader parses the safetensors file back into per-slot token dicts, then for each slot tests your Main_clip's tokenizer keys against the stored encoder names (l, g, t5xxl, etc.). Matches get re-encoded with the stored guidance/resolution settings; mismatches get reported in the Info string as excluded. So a mojo made on SDXL, loaded with a Flux clip, yields only the encoders the two have in common - the rest are dropped, and the Info output tells you exactly what happened.

Where people get burned: the Info output is not decoration. If your Positive comes back empty or weak, read it - it'll say "has no matching encoder signature and has been excluded." The mojo isn't magic; both sides have to speak at least one common encoder language. Also, Main_clip is mandatory and the loader won't guess: no clip, no conditioning.

Installing it

Hellrunner's Magical Nodes, one install for everything. ComfyUI Manager → search "Hellrunner's Magical Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Hellrunner2k/ComfyUI-HellrunnersMagicalNodes.git

Restart ComfyUI. No extra dependencies.

Troubleshooting

• Empty conditioning after load? Check the Info output for excluded encoders - your clip and the mojo share no common encoder, or you're missing a clip the mojo expected. Feeding an Additional/Special clip source in can rescue tokens that Main doesn't have.
• "Invalid Mojo File" on queue? The loader validates the file exists before running; a typo in Name or a different Output_Path is the usual cause.
• Everything loads but the image looks off? The stored latent is model-agnostic, but guidance settings were written by the original model. Adjust Mojo is the node for rewriting those after load.