Cohernet Video Sampler

The Cohernet Video Sampler is a Deforum-style node: it takes a stack of latents, denoises them one frame at a time, and carries a motion vector from each frame into the next so your video doesn't turn into a slideshow of unrelated images. It's aimed squarely at Flux, which is interesting, because Flux was never built for video - and that's exactly the gap this node tries to fill.

Before you read any further, the honest context: this is a tiny, low-traffic pack (v0.3, MIT, from Shmuel Ronen, last touched December 2024), and dedicated video models like Wan 2.2 and LTX have long since taken the mainstream use case. You reach for this when you specifically want to animate an image model like Flux - Deforum-style drifting, morphing, prompt-driven motion - without loading a video model, its extra VRAM, or its fixed output conventions. If you want actual coherent video, go use Wan. If you want Flux to move, this is one of the few tools that'll do it.

How it actually works

The mechanism is simpler than the README's marketing implies. You feed it video_latents - a LATENT whose batch dimension is your frame count, typically from VAE-Encode of a video or image sequence (the bundled example workflow pairs it with VideoHelperSuite and the FLUX1 ae.safetensors VAE). Internally it builds a standard comfy KSampler, then:

• Frame 0 gets a full denoise from noise, using frame 0's latents as the starting image.
• For every frame after that, it computes motion = current_input_latents - previous_input_latents, scales that by motion_strength, and adds it to the previous output frame - so the model sees "last frame, nudged by however the input was moving." That's the whole coherence trick: the diff of your source video steers each new generation.

Each frame uses a fresh seed offset (seed + i) and runs force_full_denoise=True. The memory story is real: it samples one frame at a time and runs torch.cuda.empty_cache() every fifth frame, so VRAM stays roughly flat at per-frame cost instead of exploding with video length. The README quotes ~8GB for 20 frames of Flux at 512×512, which tracks.

The inputs that matter

You'll set most of the familiar sampler fields (steps, cfg, sampler_name, scheduler, seed, denoise) exactly like a normal KSampler - these go straight into ComfyUI's sampler. The Flux-specific ones: keep cfg low (Flux barely uses CFG; the example runs FluxGuidance at 3.5 on the conditioning side) and try steps around 4–8 if you grab the shuttle-3 fp8 model the README recommends.

The two that define the feel:

• motion_strength - the only parameter that demonstrably does something. Higher = more aggressive motion carry-over and more dynamic transitions; lower = stabler, more static output. 0.5 is a sane start.
• denoise - overall deviation from your input latents. This is your "how much does it transform the source" knob.

The gotcha the README won't tell you

Here's the thing I want you to know going in: in the version on disk, consistency_strength and denoise_strength are accepted, stored, and never used. Open nodes.py and grep for them - they get assigned to the sampler object, and then nothing reads them. Only motion_strength reaches the sampling math. The README's elaborate four-knob tuning guide with "recommended" values for each is essentially fiction for those two. If you find the results inconsistent, don't spend an afternoon chasing consistency_strength - it isn't wired up (yet). That's also the biggest thing to know before you judge the node: it's a promising frame-chaining sampler that reads like a work-in-progress.

Install and troubleshoot

ComfyUI Manager (search "Coherent Video Sampler" or the repo name) or:

cd ComfyUI/custom_nodes
git clone https://github.com/ShmuelRonen/ComfyUI-CohernetVideoSampler.git

Then restart ComfyUI. Good news: no extra Python deps beyond torch/numpy/pillow, which ComfyUI already has - the node uses ComfyUI's own comfy modules, and there's no bundled model download. The only thing you need to source yourself is the recommended 4-step Flux checkpoint (shuttle-3-diffusion-fp8.safetensors, easy to grab from HuggingFace) if you want the Deforum look.

Real-world pain points: if you see NaNs in the log, the motion math guards against them and falls back to the raw frame - drop motion_strength a bit. Long videos should be split into segments, and keep in mind that heavy motion will fight coherence no matter what the sliders claim. For a first run, take the README's "High Quality Stable Video" preset, knock steps down for Flux, and expect to tune motion_strength more than anything else - because it's the only strength that's actually working.