H3 Relay · Cache Manager

Every stage of an H3 Relay pipeline is disk-backed and content-addressed. Rerun unchanged inputs and you get the accepted artifact back without repeating inference; change a shot and only the finishing work derived from that revision gets invalidated. That's the design that makes "resumable" work at all - but it also means a long project can quietly accumulate gigabytes of cached rerolls you rerolled and rejected. That's what the Cache Manager is for: inspecting what's actually sitting in H3 Relay's managed cache, and pruning the superseded revisions without touching anything you published.

The cache lives under ComfyUI's protected user/__h3_relay_cache system-user directory (older run names keep reading their legacy output/h3_chains and output/h3_relay paths). Browser previews are hard-linked into temp so they don't duplicate data blocks or show up as published outputs - the managed cache is strictly behind-the-scenes stuff.

The three settings

• action - inspect or prune_superseded. This is the whole point, so read the tooltip: Inspect is read-only. Prune removes only superseded immutable revisions while retaining current references. There is no "delete everything" button here, and that's deliberate.
• keep_revisions_per_shot - default 2, range 1–20. The current protected revisions are always kept on top of this recent-history count. So with the default you keep the accepted revisions plus two recent rerolls per shot.
• budget_gb - default 100. This is a reporting threshold, not a hard cap. The status string will tell you whether you're over or under budget, but the node never deletes active or protected entries just to hit a number. It's a dashboard, not an enforcement mechanism.

Outputs are cache_path (the managed root) and status (a text summary: total bytes, file count, revision groups, what was removed, and the budget comparison). The node is marked as an output node, so it's meant to sit at the end of a graph as a reporting station - or you can run it in its own tiny workflow to just check things.

The workflow shape it protects

A quick mental model for why pruning is so conservative: H3 Relay treats a shot as immutable once accepted. Your current accepted revisions are the spine of the movie - the continuation chain depends on them - so they're protected. The prune only clears immutable rerolls that nothing references anymore. If you're worried, just run inspect first, read the status, and only then flip to prune_superseded. The status output tells you exactly how much it would free.

If you're not hitting disk pressure, honestly, you can ignore this node entirely. It's a janitor, and a good workflow won't need it until a project drags on across dozens of rerolls. The one habit worth building: if a finished movie is sitting in output/ and you want to keep it, don't rely on the cache to preserve it - the cache is for resumability, and published outputs are what you actually keep.

Install via ComfyUI Manager (search H3 Relay) or git clone https://github.com/akatz-ai/h3-relay.git into custom_nodes. Needs ComfyUI 0.32.0+, FFmpeg, and the model files from MODELS.md; no extra Python deps.