MiniMax H3 Creator Segment Cache / 创作分段语义缓存计划 (Advanced EXP/T8)

If you've ever done a long video shoot in ComfyUI, you know the rhythm: generate a shot variant, judge it, change one word, regenerate - and every small change invalidates the whole expensive run. A cache would help, but caches that actually delete and move files are dangerous in a creative pipeline; the one time it eats a render you loved, you stop trusting it. This node takes the safe road: it's a cache planner, not a cache executor. It figures out what would be cached, what would hit, and what would be evicted - and it never opens, moves or deletes a single artifact. Accepted media stays protected, by design.

It's part of the pack's creator/studio family, and it thinks in "shot variants." Each variant is identified by a contract: the source, the model, the LoRAs, the prompt, the sampling settings, and the effects. Hash those together and you get a stable identity for a shot - change any ingredient and the hash changes, which is the signal for a cache miss and scoped invalidation.

What to feed it

• workspace - an H3_T8_CREATOR_WORKSPACE from the companion workspace node; this anchors what the cache applies to
• model_contract_json, lora_contract_json, sampling_contract_json, effect_plan_json - the JSON contracts describing each variant's ingredients. The defaults are minimal but valid ({"model":"unknown"}, {"loras":[]}, etc.)
• cache_index_json - the state of what you already consider cached
• maximum_cache_gib (20 default) and maximum_entries (100 default) - the LRU budget the plan is computed against

It outputs a cache_plan, plus status, hit_count, invalid_count, proposed_quarantine_count and report_json so you can see exactly what a run would reuse and what it would invalidate. The key word in all of it is proposed - the quarantine is a suggestion for a later stage, not something this node performs.

Installing it

Part of the T8mars/comfyui-minimax-h3-audio-T8 pack - search "MiniMax H3 Audio T8" in ComfyUI Manager, install, restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Update ComfyUI itself first (recent core: comfy_api.latest, comfy.weight_adapter, comfy.patcher_extension, comfy.ldm.minimax); requirements.txt is intentionally empty.

The honest take

The value here is the discipline: caching that can't delete your work is caching you can leave switched on. The cost is that it's a planning node, so by itself it doesn't speed anything up - the actual cache execution lives downstream in the studio workflow that consumes cache_plan. That makes this node strictly for people building out the T8 creator pipeline, not a drop-in speed boost. Where people get burned with similar tools is over-trusting the hit count: a "hit" only means the contract matched, not that the render on disk is still the one you want. Check your contract JSONs actually describe reality - a {"loras":[]} that ignores the LoRAs you're really using will produce confident, wrong cache decisions.