KSampler for DAAM

Here's the thing about the normal KSampler: it denoises your latent and tells you nothing about how the prompt steered it. KSampler for DAAM is the same sampler, same settings, same result - except while it works it also records where the model's cross-attention was looking at every step. Think of it as the KSampler that keeps receipts. It's the engine of the ComfyUI-DAAM pack, and it's what makes word-level heatmaps possible.

What it actually is

A drop-in for the core KSampler with two extra outputs. All the familiar inputs are there - model, seed, steps, cfg, sampler_name, scheduler, positive, negative, latent_image, denoise - and they behave identically. That's not a coincidence: the latent output is computed by literally calling ComfyUI's own sampler code, so you get every sampler and scheduler ComfyUI ships, and denoise/img2img semantics work exactly as you expect.

The difference is what happens around the sample. Before denoising, it patches the model's cross-attention modules with logging versions - one patcher per architecture, chosen automatically: CrossAttentionPatcher for SD 1.5 and SDXL, SD3AttentionPatcher for SD3, FluxAttentionPatcher for Flux Dev (still marked beta in the README). On every step, each cross-attention map gets captured, upsampled toward 64×64, and stashed. After the last step the maps are aggregated across layers and timesteps into the two outputs:

• latent - the standard denoised latent, wire it to the VAE decode like always.
• pos_heatmaps - raw positive-prompt attention heatmaps, for the analyzer.
• neg_heatmaps - same, for the negative prompt.

These are the raw material. On their own they're not visual - you feed them into DAAMAnalyzer to get colored overlays, or DAAMPreviewImage for the hover tooltip.

The gotcha that eats an hour

KSamplerDAAM is lazy on purpose. If you don't connect the pos_heatmaps output to anything, it never records positive heatmaps; same for the negative one. Check the source and you'll find is_output_connected(prompt, node_id, 1) deciding whether to even enable the patcher. Your image comes out perfectly, and the analyzer shows nothing, and you tear your hair out. Wire both heatmap outputs before you start debugging.

The honest cost

Recording every cross-attention map on every step is real overhead: sampling gets slower and peak memory climbs. This is a debugging instrument, not your default sampler. Keep a dedicated DAAM workflow, swap it in when a prompt misbehaves, and leave the production graph alone. Also worth knowing: the cfg default of 8 is copy-pasted from an SD 1.5 era where that made sense; on SDXL you'll usually want lower, and Flux's guidance-distilled semantics don't play by the same rules at all. The sampler runs whatever you type - it doesn't save you from your own cfg choices.

Install

The whole pack in one go - ComfyUI Manager (search ComfyUI-DAAM), or:

cd ComfyUI/custom_nodes
git clone https://github.com/nisaruj/comfyui-daam.git
cd comfyui-daam
python3 -s -m pip install -r requirements.txt

Restart ComfyUI and the node appears under daam-nodes. The only dependency is matplotlib, no model downloads. When would you reach for it? When the output ignores a prompt word and you want proof of what the model was actually paying attention to - or before a LoRA training run, to check whether your concept is landing where you think it is.