Conduit Latent Cache

Conduit Latent Cache is the full-pipeline caching node: it wraps the entire KSampler step and, if you ask for a generation that exactly matches one it's already done, hands back the finished latent instantly instead of re-sampling. It's the deterministic end of the Conduit caching story - and it's one of the few nodes in this pack that genuinely does the heavy thing it claims.

How it works

You give it everything a KSampler wants: model, positive, negative, latent_image, seed, steps, cfg, sampler_name, scheduler, denoise. On each run it hashes the whole configuration - seed, steps, cfg, sampler, scheduler, denoise, the latent tensor, and the conditioning - into a single key, then checks an in-memory cache (50 entries, LRU, stored as CPU copies to keep VRAM free). A hit returns the cached latent immediately; a miss runs a real comfy.sample.sample pass and stores the result.

The cache_status STRING output tells you which happened:

HIT | Entries: 12 | Hit rate: 85.0%

Outputs are latent (LATENT) and cache_status (STRING), so the latent plugs straight into your VAE decode.

The honesty section

The key includes the conditioning, the latent tensor, and every sampling parameter. That means you get a cache hit only when everything is bit-for-bit identical - change the prompt, change the seed, change the resolution, and it's a miss and a full re-sample. That's by design (it's how it stays deterministic), but it shapes when this node is useful:

• Re-running the exact same generation (reproducibility, re-rendering a workflow, comparing downstream post-processing) - instant.
• Seed farming with different seeds - no hits at all; every new seed is a full run. This is where the Embedding Cache helps instead.
• Iterating on the prompt - no hits; keys change every time.

So it's a replay cache, not a speed-up-for-iteration cache. The other thing to know: the README's talk of checksum-verified, disk-backed deterministic caching is the roadmap; today the cache is in-memory only, wiped on restart. And it's honest about determinism in one important way - the internal comment notes batch size must stay 1 for the hashes to be meaningful, which lines up with the community's own rule that fixed seed + batch 1 is what makes runs reproducible.

Inputs and outputs that matter

All the sampling parameters are required (seed, steps, cfg, sampler, scheduler, denoise), and they're exactly the values that go into your normal KSampler - if you change one, the key changes, which is the behavior you want to understand before wiring it in. force_recompute (optional, default false) bypasses the cache for that run, useful when debugging or after a model swap.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/joe002/comfyui-conduit-optimizer

Or ComfyUI Manager → search "comfyui-conduit-optimizer" → restart. No downloads; torch 2.0+ only.

Common issues

The classic gotcha is the model blind spot: the cache key doesn't include which model you're using. Same settings, new checkpoint, and a hit can return the old model's latent - the author's own code notes this exact failure mode. Clear the cache (ConduitCacheClear) or tick force_recompute whenever you change checkpoints. And remember that a cache filled with 50 entries of one config means your pipeline is doing almost no work on re-runs - that's the whole point, so don't mistake it for a hang.