Nodes/ComfyUI-LTX-Attention-Toolkit/LTX Attn — Store Inspect
ComfyUI Node

LTX Attn — Store Inspect

Read the receipts on your capture

By g-raw·Created 3 months ago·Updated 2 months ago· 2
LTX Attn — Store Inspect
  • trigger
  • store_summary

Debugging node, no glamour, frequently the thing that saves you. When a visualization node returns an empty grid or an error about a missing map, you need to know what the capture actually contains - which blocks, how many steps, how many heads, whether the full map is present, whether the key/query maps are there. That's Store Inspect: it prints the AttentionStore contents to the console and hands them back as a STRING.

The pack's captures have modes and sub-modes (reduced, full_fp16, hybrid, full_targets sparse dicts), and the difference between "block 24 has a dense [32, Sq, Sk] map" and "block 24 was captured via full_targets, so it's a sparse per-head dict" is the difference between a working Query Map and an error. This node tells you which one you're looking at, per block.

How it works

It inspects whichever AttentionStore is active (or creates and inspects default if none is - a nice touch), then walks both the SA and CA sections. Per block it reports: number of captured steps, head count, approximate timestep of the last step, map presence and shape (or sparse, heads=[...] for a full_targets block), and whether the reduced key/query maps are present. That last bit is the tell for whether a reduced-mode capture is complete.

The only input is trigger (type *), which accepts anything - this node is an output/debug terminal, so you wire a dummy or a string into it just to force execution at the right point in the queue. It's an OUTPUT_NODE, and its one output, store_summary, is a STRING with the full report.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/g-raw/ComfyUI-LTX-Attention-Toolkit.git

Restart ComfyUI. No extra dependencies, no model files. Same work-in-progress caveat as the rest of the pack.

Common issues

The classic debugging sequence when something looks empty: run a capture, then run Store Inspect after the KSampler (the two-run workflow applies here too - the store only exists once the capture generation has run), and read which blocks actually recorded data and in what form. If a block shows zero steps, your target_blocks/capture_steps filters excluded it. If it shows a sparse map, you know exactly why the multi-head viewers refuse it. The other gotcha is that blank-handle behavior inspects the currently active store - if you have multiple stores and the report doesn't match expectations, that's why.

Categoryg_raw/LTX/Profiler

Inputs (1)

NameTypeDefaultDescription
trigger*

Outputs (1)

NameTypeDescription
store_summarySTRING