(deforum) Cache Latent

The latent-space sibling of (deforum) Cache Image. (deforum) Cache Latent takes a LATENT, stores a copy in the pack's global cache under a numbered slot, and passes it through. A matching (deforum) Get Cached Latent node can later fetch it by slot number. Where this matters is the stuff you only want to encode or sample once but need in several places - the cleanest example being a base latent you keep feeding back into the sampler at frame zero, or a reference latent you reuse for a recurring conditioning. It's the same side-channel trick as the image cache, one level further down the pipeline, before the VAE decode.

How it works

Mechanically identical to the image cache: a module-level dict keyed by integer cache_index (0–16), with the latent stored on write and returned unchanged. One important difference from the image version: the latent is stored without a clone in this node - it keeps a reference to the tensor you gave it. Latents are mutable in ComfyUI (a sampler can update the same dict in place), so if something downstream mutates the cached object, the slot contents can change under you. In practice most Deforum flows treat latents as immutable snapshots, so it rarely bites, but it's worth knowing if you're debugging mysterious drift.

As with the image cache, the data lives in RAM for the session - no disk, gone on restart. Slot numbering is yours to manage, and two writers to the same slot means the last one wins.

The inputs and outputs

• latent - the LATENT to stash.
• cache_index - slot 0–16.
• LATENT - output, pass-through.

Consume it with DeforumGetCachedLatentNode using the same index.

When it's worth it

The classic Deforum use: your animation needs a fixed reference latent for the first frame, but the graph path that produces it is nowhere near the sampler that needs it. Caching it at the start and fetching it at the sampler keeps the graph readable. It's also the right tool when you want to save work - if a latent costs a full VAE encode, caching it means computing it once instead of once per consumer. That's the honest case for the latent cache over the image cache: it's a performance move, not just a routing convenience. If you only need the decoded pixels, prefer the image cache; if you need to re-sample from a latent, this is the one.

Installing it

Part of Deforum Nodes (XmYx). ComfyUI Manager → "Deforum Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/XmYx/deforum-comfy-nodes.git

Restart and let first-boot install.py finish (opencv-contrib-python, moviepy, numpy<2.0.0, deforum-studio backend). Python 3.10 per the README.

Where people get burned

The same index-collision hazard as the image cache - two writers on one slot, silent overwrite, wrong latent downstream. And the mutation caveat: because the slot holds a live reference, a node that changes the latent in place (some samplers write back) can corrupt what the getter returns later. When that shows up as "the cached latent changed by itself," cache a copy or don't route mutable tensors through it. Keep your slots documented and your latent immutable, and this node is boring in the best way.