Nodes/Comfyui-Echo-WM-T8/Echo-WM T8 · Causal Flash Generate
ComfyUI Node

Echo-WM T8 · Causal Flash Generate

From one frame to a 4-step world-model clip

By T8mars·Created a day ago·Updated about 18 hours ago· 1
Echo-WM T8 · Causal Flash Generate
  • runtime
  • action
  • image
  • video
  • metadata_json
promptA cinematic world viewed from a moving camera.
presetsmoke_1s_256x128
width256
height128
num_frames25
fps24
seed42
include_audiotrue
action_overlayfalse
allow_high_resourcefalse
timeout_minutes240

This is the node that actually does the thing. "Echo-WM T8 · Causal Flash Generate" takes a first-frame image, a prompt, and the camera action from its sibling nodes, and runs Echo-WM's Flash Preview pipeline - the 4-step distilled causal model that rolls the world forward from your starting frame instead of generating an unrelated clip. If you've felt the LTX-era tug-of-war between "clean, slow, many steps" and "fast preview", this is squarely the fast side of it: four timesteps (1000, 750, 500, 250) per block with a chunk-causal attention cache, which is how a "preview" model gets anywhere close to interactive.

Mechanically it's honest about what it does: the pack stages your image to a temp PNG, launches the dedicated Echo-WM Python from your Runtime node on inference_wm_causal.py as a subprocess, pins CUDA_VISIBLE_DEVICES to the GPU you chose, and waits - streaming a log. When the child finishes, its two outputs are a native ComfyUI video object - no exploding the movie into an in-memory image batch, which is why you need a recent ComfyUI build with native VIDEO support - and metadata_json, a JSON string with the preset, prompt, action, resolved runtime, timesteps, and timings. The output MP4, sidecar .json, and .log all land under ComfyUI/output/echo_wm_t8/, and because this is an output node it previews in the UI directly.

The inputs that matter

  • image, prompt, runtime, action - the four wires. Load any IMAGE as your first frame (LoadImage → image), pull runtime from Isolated Runtime and action from Action. The default prompt, "A cinematic world viewed from a moving camera.", is a fine starting point; Echo-WM Flash is caption-driven per-frame, so say what the world is rather than describing camera moves.
  • preset - smoke_1s_256x128 (256×128, 25 frames, 24 fps) or low_10s_256x128 (241 frames). A preset overrides width, height, num_frames, and fps - those widgets only take effect when preset is custom. So yes, you can tweak resolution all you like while smoke_1s_256x128 is selected and nothing will happen. That confuses people every time.
  • num_frames - accepts only 1 + 24n (25 to 2401), and it must be exactly one more than your action's total frames. Keep the matching preset pair from the Action node's README table and this stays painless.
  • include_audio - on by default, because Echo-WM is audio-visual and generates environmental sound alongside the picture. Flip it off if your audio stack misbehaves.
  • action_overlay - burns the action HUD onto the video. Only bother if you want to see the steering, and it requires ffmpeg_bin set on your Runtime node.
  • allow_high_resource - the guard rail. Requests above 384×224 or 241 frames refuse to run without this flipped on, and that's not bureaucratic: the node also checks free system RAM and won't start under ~36 GiB free, warns below 44, and demands ~90 GiB total for high-res runs. A Gemma-3-12B bf16 text encoder plus an LTX-2.3-scale DiT is a lot of resident memory.

What you'll actually hit

The defaults are deliberately tiny (256×128 at 25 frames) so your first run is a cheap smoke test - the README's verified path is exactly that. Beginners get burned in three spots: picking a preset and then fighting the resolution widgets (preset wins), mismatching action length against num_frames (the node refuses before loading the model, which is good - it's a ~10-line fix, not a wasted 40 minutes), and treating 256×128 as the real quality tier. This is a preview integration: Echo-WM's real output is 720p, and squeezing that through the guarded high-res path means having the RAM for it. If the run dies, the log file next to the MP4 output is your diagnostic; timeouts default to 240 minutes via timeout_minutes, and cancellation kills the child process cleanly.

Install is the same story as the rest of the pack - clone T8mars/Comfyui-Echo-WM-T8 into custom_nodes (or ComfyUI Manager, searching "Echo-WM T8"), then configure the separate Echo-WM conda environment and gated model bundle through the Runtime node. No Python packages get pip-installed into ComfyUI itself. And a note on expectations: this is brand-new (the model mirror went up days ago) and license-gated to research/non-commercial use under the LTX-2 Community License - so you're an early adopter, and early-adopter bugs belong on the repo's issue tracker, not in your workflow folder.

CategoryEcho-WM T8

Inputs (14)

NameTypeDefaultDescription
runtimeECHO_WM_RUNTIME
actionECHO_WM_ACTION
imageIMAGE
promptSTRINGA cinematic world viewed from a moving camera.
presetCOMBOsmoke_1s_256x1283 options: smoke_1s_256x128, low_10s_256x128, custom
widthINT256128–1280
heightINT128128–1280
num_framesINT2525–2401
fpsINT248–60
seedINT420–9223372036854776000
include_audioBOOLEANtrue
action_overlayBOOLEANfalse
allow_high_resourceBOOLEANfalseRequired above 384x224 or 241 frames. Large requests can exhaust system RAM.
timeout_minutesINT2401–1440

Outputs (2)

NameTypeDescription
videoVIDEO
metadata_jsonSTRING