LazyCache
LazyCache — EasyCache's dumber, more compatible sibling
- model
- MODEL
LazyCache is the backup plan nobody tells you about until the main plan fails. Same idea as EasyCache - watch how much the latent changes between steps and skip the ones that aren't worth computing - but implemented the lazy way. The author, who invented it while building the native EasyCache, is blunt about it in the node description: "overall works worse than EasyCache, but better in some rare cases AND universal compatibility with everything in ComfyUI."
If EasyCache is the finely-tuned option, LazyCache is the "will run anywhere" one. Same inputs, same output, ships with ComfyUI core since August 2025. It's the node you swap in when EasyCache misbehaves.
The difference that matters
EasyCache is careful. It tracks the cache per conditioning - meaning it separates your prompt and negative-prompt passes, caches each one's diff separately, and only skips a step when both can be safely reused. That's precise, and it's why it preserves quality better.
LazyCache doesn't bother. It wraps the sampling step at a higher level (the PREDICT_NOISE call, before and after CFG) and caches a single diff of the combined latents. It doesn't know or care which conditioning produced what. The result is a much simpler implementation that's compatible with anything that runs a standard sampling step - even models where EasyCache's per-condition bookkeeping falls over - but it reuses cruder information, so it's generally less accurate and the quality hit is bigger for the same threshold.
That's the whole trade: EasyCache when it works, LazyCache when it doesn't. The author's own guidance is "always favor EasyCache first."
Inputs and output
- model - MODEL in, patched MODEL out, wire it into the KSampler. One node in the chain, nothing else changes.
- reuse_threshold (default 0.2) - the same single knob as EasyCache. Higher = more skipping, more speedup, less fidelity.
- start_percent (0.15) and end_percent (0.95) - the skip window. Early steps own composition, late steps own detail; nudge start_percent up or end_percent down if the output drifts.
- verbose - logs per-step skip decisions so you can actually see what the threshold is doing instead of guessing.
When to actually use it
You probably won't, most of the time. The realistic play is: build the workflow with EasyCache, and if a particular model produces artifacts, weird flickering, or doesn't seem to skip at all, swap in LazyCache and see if it behaves. In the rare models where the per-cond caching trips up, LazyCache's anything-goes approach can be the difference between a workflow that runs and one that doesn't.
Gotchas
- Don't stack them. Both patch the same sampling path; one cache node is enough. You're not doubling your savings, you're asking two different bookkeepers to fight.
- Same artifact risks as EasyCache. It's still a step-skipper, so expect the same "great for static shots, rough on motion" behavior, and the same conflict reports when combined with step-reducer LoRAs like LightX2V.
- It's also experimental. LazyCache got a dedicated fix in February 2026, so behavior has shifted under it since launch. If a shared workflow with LazyCache misbehaves after an update, that's the first thing to suspect.
LazyCache is the honest fallback: slightly worse, universally compatible, and cheap to try. Keep it in your pocket for when the fancy version won't cooperate.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | The model to add LazyCache to. | |
| reuse_threshold | FLOAT | 0.200–3 | The threshold for reusing cached steps. |
| start_percent | FLOAT | 0.150–1 | The relative sampling step to begin use of LazyCache. |
| end_percent | FLOAT | 0.950–1 | The relative sampling step to end use of LazyCache. |
| verbose | BOOLEAN | false | Whether to log verbose information. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | The model with LazyCache. |