ChronoEdit_SM_KSampler

If ChronoEdit_SM_Model loads the brain, this is the node that thinks. The KSampler is where the denoising loop actually runs, and it's also where a 14B model either fits in your VRAM or doesn't. It takes the model, your text conditionings, and the image conditioning from ChronoEdit_SM_Latent, and returns a LATENT that ChronoEdit_SM_Vae turns back into frames.

The inputs, in order of how often you'll touch them

• model - the ChronoEdit_SM_Model output (optionally after the LoRA node).
• positive / negative - standard ComfyUI CONDITIONINGs from CLIPTextEncode. These come from the Wan text encoder, umt5_xxl_fp8_e4m3fn_scaled.safetensors, loaded with a core CLIPLoader (type wan). Don't try to skip this with an SD text encoder - the model expects Wan embeddings.
• cond - the CONDITIONING from ChronoEdit_SM_Latent. This carries your image's latents, its CLIP-vision embeddings, and the frame count. Nothing else can feed it.
• seed - any int; the only input you'll randomize for variety.
• steps - defaults to 8. That default is not an accident; it assumes the distill LoRA from ChronoEdit_SM_Lora is loaded. Without it, 8 steps is too few. With the upscale LoRA stacked, the README wants >12.
• flow_shift - defaults to 2.0. A Wan-family scheduling parameter baked into the UniPC scheduler here. Leave it at 2.0 for 480p-class work; you generally don't need to touch it.
• guidance_scale - defaults to 1.0, which is the distilled-model CFG value. This isn't SD; 7.0 here would cook your edit.
• offload_model - defaults on, and you want it on. It empties VRAM between steps.
• block_num - the one people misread. It sets how many transformer blocks move together during block-level group offloading. Smaller number = smaller chunks = lower peak VRAM but more host↔GPU shuffling, so slower. The README's example workflow runs it at 4; if you're on a 12GB card and hitting OOM, drop it to 1–2.

What the sampler is doing under the hood

It configures UniPCMultistepScheduler with your flow_shift, applies classifier-free guidance via guidance_scale, and offloads the transformer at the block-group level using block_num. That block-level offload is the quiet hero: it's how a 14B transformer runs on consumer cards at all, and it's why the pack says "VRAM >8G" while the weight file alone wants more than that.

There's also num_temporal_reasoning_steps (default 50). This is the step at which ChronoEdit, in 29-frame "temporal reasoning" mode, collapses the long reasoning sequence down to just the first and last frames and finishes the edit on those. Here's the trap: the default 50 is above your default 8 steps, so at 8 steps the collapse never fires - the sampler just denoises all 29 frames. That's fine for most edits; it only becomes the knob you want if you're deliberately raising steps to let the model "reason" longer before committing to the edited frame.

The wiring

Feed its Latent output into ChronoEdit_SM_Vae. From there it's frames on screen, a saved video, or - the part people actually came for - the last frame of the batch, which is where the edit lives. Install is the pack's shared recipe (Manager search ComfyUI_ChronoEdit_SM, or clone + pip install -r requirements.txt); there's nothing extra to download for this node specifically, it just needs everything else in the chain loaded.