Powder Cache Stats

Powder Cache Stats is the tachometer for the engine room of the E2GO "Powder" node pack. Every Powder node - the Lora Loader, the Conditioner, the Styler - keeps internal caches to make repeated runs fast. This node tells you what's actually in those caches, which is exactly the information you need when things feel slow or results look stale and you're not sure why.

It's a diagnostic. You won't use it in every workflow, and you shouldn't. But when you're tuning batch LoRA comparisons and wondering whether the cache is helping or lying to you, it's the difference between guessing and knowing.

How it works

The node has no inputs. It's an output node that takes a snapshot of every internal cache in the pack and returns it as one JSON string, while also writing that same JSON to the ComfyUI console log.

The deliberately boring detail that makes it useful: IS_CHANGED returns NaN, so the node always executes when you queue the workflow. Most nodes skip execution if nothing changed since the last run - this one refuses to be skipped. Drop it in, queue, and you get a fresh reading every time. That's why the README says to use it during debugging and remove it for production.

What the output tells you

The stats output is a STRING containing JSON with six entries. Here's what matters:

• lora_raw_cache - how many LoRA safetensors files the loader currently has in raw memory (max 16, TTL 30 minutes). If you're cycling through dozens of LoRAs in a comparison grid, this tells you whether old ones are being evicted or piling up.
• lora_patcher_cache - the model patcher results, the heavier stuff. size is live entries; raw_entries is total before dead weakrefs get pruned. A gap between the two means cleanup is pending.
• conditioning_cache - encoded text conditioning held on CPU (max 64). The one that matters if you're chasing stale prompts.
• clip_dim_cache - learned conditioning dimensions per CLIP hash, used to size the encodings correctly.
• clip_hash_refs - how many CLIP objects are still alive from the pack's perspective.
• styles_loaded - how many styles are in memory after the last directory scan.

How to read it

Most people want two numbers: conditioning_cache.size (am I caching what I think I am?) and lora_patcher_cache.size (am I re-patching LoRAs on every run?). If the conditioner isn't caching but you expect it to, the count will sit at zero - that's a hint you're on a model type where auto cache mode intentionally disables caching (FLUX, T5, quantized CLIPs). If lora_raw_cache maxes out, consider that a sign you're hammering more distinct LoRAs than the cache is sized for.

Installation

Same as every node in this pack - one install gets you all eight:

cd ComfyUI/custom_nodes
git clone https://github.com/E2GO/e2go-comfyui-nodes.git e2go_nodes

Restart ComfyUI. Or search e2go_nodes / E2GO in ComfyUI Manager. No extra Python packages to install; the README verifies ComfyUI 0.17+.

Common issues

The main gotcha is expectations. This node reports this pack's caches - ComfyUI's own model cache, and caches from other packs, won't show up here. If you're diagnosing a memory problem and this node shows everything nearly empty, the memory is being held by ComfyUI core or another custom node, not by Powder. Also note the JSON is written to the log as well as the output, so if you forget to wire up the output, the data is still in the console. For deeper cache debugging, the pack respects the E2GO_LOG_LEVEL environment variable - set it to debug (and optionally E2GO_CACHE_DEBUG=1) for per-node cache HIT/MISS lines.

It's a quiet little node that earns its place during any cache-related debugging session, and the fact that it always runs when queued makes it genuinely trustworthy when you need a current reading.