H3 Conditioning Cache

You didn't place this node. You found it in your graph, or in the node list under EasyUse/H3/dev, and you're wondering whether you broke something. You didn't. H3 Conditioning Cache is one of the internal pieces of ComfyUI-Easy-Media's MiniMax H3 MultiTrack pipeline, and its whole reason for existing is that regenerating segment 4 of a six-segment project shouldn't drag the other five segments' prompt encoding along with it.

Where it comes from, and why it exists

If you're building long H3 clips, you're running the same chain - encode prompts and reference media, build the latents, sample, decode, save - once per timeline segment. easy multitrackProject doesn't execute that loop itself; it builds the whole graph at run time and hands it back to ComfyUI to expand. That's why you suddenly see a small city of nodes you never wired, this one sitting right after the conditioning encoder.

That encode step isn't cheap. Prompts plus reference images, video, audio and keyframes go through CLIP and both VAEs to produce conditioning and an initial audio/video latent - and when all you want is a different seed, none of that actually changed.

How it actually works

The trick is lazy inputs. Both conditioning and latent are marked lazy, so ComfyUI asks the node first (check_lazy_status) whether it needs them this run. If both are unsupplied, every upstream media cache reported a hit on the tracks_info it was handed, and the pool's scope is still valid, the node loads the saved conditioning from disk and returns an empty list - don't evaluate those inputs at all. The encoder never runs. That's the entire win.

On a miss it asks for conditioning and latent, the encoder runs as normal, and the node writes a fresh artifact and passes your values through untouched. Nothing downstream can tell the difference.

The artifacts live in ComfyUI's temp directory, not the output folder:

ComfyUI/temp/easy_media/h3_conditioning_cache/
  cache.json
  conditioning_0.safetensors
  conditioning_1.safetensors

Three details explain the behaviour you'll observe. The pool keeps the five most recently used segments and touches each file on restore, so it's an LRU - the segments you keep re-running stay warm. Validity is a signature, not a timestamp: an identity hash of the model, clip, vae and audio_vae you fed in, plus the project name, so swapping a checkpoint wipes the pool rather than risk mixing encoders. And the initial AV latent is stored as compact metadata describing a zero-filled latent rather than the tensor, which keeps the files small; the log breaks the size down per category after each write.

The inputs and outputs that matter

You'll never set these by hand - the expansion fills them in. But this is the wiring, if you're reading the node to work out what broke:

• project_name and segment_index - which project's pool, and which segment. segment_index is zero-based here, unlike segment_start_number on the project node.
• tracks_info - used only to read the upstream media cache status.
• task_output_ready - a forced string input. It's a dependency token, not a value.
• model, clip, vae (and optional audio_vae) - not used for encoding on a hit; they exist to make the signature.
• conditioning, latent - the lazy pair above, i.e. the real encoder outputs.

The outputs are just conditioning and latent, wired into the sampler exactly where easy minimaxH3ToVideo used to feed them.

Installing it

It comes with the pack, so there's nothing separate to install.

cd ComfyUI/custom_nodes
git clone https://github.com/yolain/ComfyUI-Easy-Media
# restart ComfyUI

Or use ComfyUI Manager and search ComfyUI-Easy-Media - same author as the widely used ComfyUI-Easy-Use pack, though Easy-Media itself is young (1.3.x, September 2026; this caching work landed in the 1.3.2 pre-release line). The pack ships no Python dependencies of its own, but the README asks you to have FFmpeg on your PATH first, since the same pack writes, merges and subtitles video, and hard context continuity needs ComfyUI 0.34.0+ for native H3 audio/video keyframes.

Where people get burned

Clearing ComfyUI's temp folder clears this cache. Any cleanup script, container rebuild, or --temp-directory change means the next run re-encodes every segment. Expected, not a regression.

One edited prompt can cost you the whole warm pool. If any upstream media cache misses, the node treats the scope as invalid and resets it rather than half-restoring a run. So the caching pays off when a re-run is mostly unchanged - the regenerate-one-segment workflow the project node is built around, via segment_start_number and segment_count.

A bad artifact is deleted, then complains. If a cache file fails to load, the node removes it and raises "Failed to restore H3 conditioning cache; rerun the project to rebuild it". Rerun and it rebuilds. For a guaranteed cold start, deleting this folder is safe - it's a pure cache:

rm -rf ComfyUI/temp/easy_media/h3_conditioning_cache

Don't confuse it with context continuity. This node caches conditioning and the initial latent; the join you watch in the final video comes from separate low- and high-resolution context latents under ComfyUI/output/easy_media/projects/<project_name>/. Wiping this cache won't repair a stale join, and the README is blunt that changing editor dimensions, upscale_by, or a previous segment's selected version can leave the context chain inconsistent.

One last thing: parts of this node's logging are still in Chinese. "命中恢复缓存" is a cache hit, "首次加载" is a first load. It looks alarming the first time and means nothing bad.