Video Frame Limit (Oli)

Video models in ComfyUI have a failure mode so common it's basically a genre: you ask for a 15-second clip, watch it grind for twenty minutes, and get an out-of-memory crash somewhere past frame 70 - after it already spent all that compute. Video Frame Limit (Oli) exists to make that crash predictable. You tell it your resolution, fps, and how long you want the clip; it tells you how long your VRAM can afford.

The premise is real, not theoretical. "Out of memory" plus video plus ComfyUI is one of the most-churned complaint threads in the community, and it got worse as video models got heavier. A node that estimates the ceiling before you commit is worth having.

How the math works

This isn't a random fudge factor. The node derives a bytes-per-frame budget from transformer peak memory first principles:

bytes_per_latent_frame = 5 × (width÷8) × (height÷8) × hidden_dim × 2
max_frames = total_vram × safety_margin ÷ bytes_per_latent_frame

The 5 is TENSOR_COPIES - Q, K, V, attention output, and residual activations each materialize a copy of the latent. The ÷8 is spatial VAE compression. hidden_dim is auto-detected from the connected model, falling back to a parameter-count estimate, then to a generic 1536.

Two design decisions make it more right than most hand-rolled calculators:

• It uses total VRAM, not free VRAM. ComfyUI offloads weights layer by layer, so peak activation memory during inference scales with total VRAM rather than "total minus model size." Basing it on free VRAM would undercount.
• It snaps frame counts to the n×4+1 pattern that Wan, HunyuanVideo, CogVideoX and friends require (4 latent frames per temporal chunk, plus a reference frame), so the capped number is one the sampler will actually accept.

Connect the model input and it detects hidden dim and shows you the model name; leave it unconnected and it uses the generic fallback. Either way, after each run it prints the detected VRAM, model, dim, and requested-vs-capped frames right on the canvas - which is why it doubles as a standalone config panel for the whole generation.

The inputs that matter

• width / height - your generation resolution (832×480 by default).
• fps / duration - what you're asking for. duration is in seconds; requested frames = duration × fps + 1 (the reference frame).
• safety_margin - fraction of total VRAM to budget. 0.95 leaves 5% headroom; if you're cutting it close, lower it.
• model - optional, but connect it. Auto-detected hidden dim is what turns the estimate from generic into model-specific.

Outputs are mostly pass-throughs - width, height, fps - plus the two that matter: frames (the capped count you feed your video sampler) and duration (what the clip will actually be after capping).

Install & gotchas

Manager → Oli Prompt Tools, or:

cd ComfyUI/custom_nodes
git clone https://github.com/magicoli/comfyui-oli-prompt-tools

Restart. No dependencies.

Honest limits: it estimates activation memory, not the whole picture. The text encoder, VAE decode, and output post-processing live outside this model and can still push you over on a tight card. And if CUDA isn't available it bails out and returns your requested frames uncapped. Treat the number as a smart starting point - and if a model genuinely fits with zero room to spare, knock the safety margin down a notch.