Wan video frames
Wan's magic number is 81 — here's a node that keeps reminding you
- frames
Wan - the ByteDance video model family behind 1.3B, 2.1, and 2.2 - has a native context of 81 frames. That number is the anchor of every serious Wan workflow, and the ecosystem docs confirm it's still 81 frames at the current edge; anything longer means chunking, with more VRAM, longer runs, and identity drift across the seams. Wan video frames (Wan frames mc) is a glorified constant built around that fact: one integer input called frames, default 81, one integer output. It doesn't compute anything, it doesn't enforce anything - it just gives you a labeled place to set the count and feed it into the sampler.
That sounds trivial, and it kind of is. It's also exactly the kind of trivial that keeps a workflow legible. A named node in the graph beats an anonymous number buried in a sampler widget, and it's the one place you go when you want to try 97 frames instead of 81 without hunting through the spaghetti.
How it works
Mechanism: pass-through. frames in, frames out, nothing in between - the execute method literally returns its input. The input's step of 4 (min 1, max 4096) isn't random: Wan's temporal autoencoder groups frames in fours, and 81 = 1 + 20×4, so counts of 1 + 4n are what the model handles natively. That step is a hint, not a guard - the node will happily output 82 if you type it. The model just won't love you for it.
Where it goes: into the frames input on a Wan sampler or wrapper - ComfyUI's native Wan nodes, or Kijai's WanVideoWrapper if that's what you run. Keep it at or near 81 for one coherent clip; push past it and you're into chunked territory, which is Wan's known weak spot.
The inputs and outputs that matter: just frames. Default 81. That's the whole list, and that's fine - a node this small doesn't need more.
Why use it instead of a plain integer
Honest answer: you don't strictly need it. A core PrimitiveInt gives you the same value on the wire. But Wan generations are slow enough that you're building a repeatable template, not one-off runs - and a node literally labeled "Wan video frames" tells anyone who opens that workflow what the number means, while the 81 default is a constant reminder of where Wan actually lives. For a 5-minute-per-clip model, that kind of self-documenting graph earns its keep.
It also sits alongside its siblings in the same pack: AspectSize3_mc for arbitrary ratios, LTXVsize_mc if you're cross-shopping LTX Video. The author clearly built the pack around a video workflow, and this node is the frame-count corner of it.
Install
Part of the mc_cascade_res pack under MC nodi/Wan - install once, get all four nodes. ComfyUI Manager: search mc_cascade_res. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/tester4488/mc_cascade_res
Restart ComfyUI after cloning. No models to download, no Python dependencies, no config - it's pure utility code. One requirement shared by the whole pack: it uses ComfyUI's newer V3 extension API (comfy_api.latest), so keep ComfyUI reasonably updated or the pack won't load at all.
The one thing to remember as you use it: 81 is the sweet spot, and this node defaults there on purpose. Treat anything past it as a deliberate trade - longer clip, chunking, drift - rather than a free upgrade.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| frames | INT | 811–4096 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| frames | INT | — |