🎬 MuAPI Extend Video

Every video model in this pack returns a short clip. Ten seconds if you're lucky, usually five. 🎬 MuAPI Extend Video is the node that picks up where the last one stopped - and the first thing to notice is what it doesn't have: there's no prompt field. Not an oversight. The extend endpoints already know your prompt and your frames; you're paying for N more seconds in the same world, not describing a new one.

How it works

You give it a request_id - the continuation handle that 🎬 MuAPI Text-to-Video and Image-to-Video return as their third output - plus a model, quality (basic/high) and duration. The pack POSTs {request_id, quality, duration} to the extend endpoint and polls for the result. The model looks up that generation server-side, reads the last frames, and generates forward from them.

That's the mechanism, and it has one hard consequence: it only extends jobs that MuAPI made. A request_id is an id on their servers, tied to your account. You cannot hand this node an mp4 from your hard drive, and you can't extend a clip that came from a local Wan render. Clips from someone else's account won't resolve either.

The model list matches the job to an extender: seedance-v2.0-extend, seedance-v1.5-pro-video-extend (with a -fast variant), veo3.1-extend-video, wan2.2-spicy-video-extend, wan2.7-video-extend, grok-imagine-extend, seedance-2-vip-extend and its 1080p sibling, ltx-2.3-video-extend, pixverse-v6-extend, and custom. Match the extender to the family that made the clip and continuity is far better; extend a Seedance clip with a Veo extender and you're asking two models to agree about a scene neither of them shares.

duration is an INT from 5 to 10 with a step of 5, so you're choosing five more seconds or ten. Treat it as the length of the extension request rather than a new total and check the returned clip - endpoint semantics vary.

Chaining is the whole trick

Three outputs: video_url, first_frame, new_request_id.

new_request_id is a new handle for the extended generation, which means the node is chained with itself. Wire new_request_id into the next Extend node's request_id, set that one to 5 seconds, and you've built 5 → 10 → 15 → 20. It's the closest thing this pack has to a long-form clip, and it's the same problem every video ecosystem is grinding on - the KB's note on LTX's ltxv-13b-i2v-extend.json workflow and the Wan pipeline docs cover the local versions of exactly this trick. Reach for this node when the source clip is a MuAPI generation and you'd rather not round-trip it through a local video model.

first_frame is the opening frame of the new segment as an IMAGE - a cheap continuity anchor if you'd rather drive the next step with a local model.

Install

Manager → Install via Git URL → https://github.com/SamurAIGPT/muapi-comfyui → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/SamurAIGPT/muapi-comfyui
pip install -r muapi-comfyui/requirements.txt

Nothing model-shaped to download - the requirements are requests, Pillow, numpy, torch, opencv-python, and only the last is likely to be new.

Things that will annoy you

Leave request_id empty and it stops with "request_id required." - count that as a feature, because the alternative is silently extending nothing.

Chaining multiplies the wait. Each extension is a fresh paid render going through the same 10-second polling loop with a 900-second ceiling, so a four-step chain is four chances to hit a timeout on a job that is still running on their side. Check the dashboard before re-queueing.

And there's no prompt, so there's no steering. If you want the next five seconds to go somewhere specific - a new action, a camera move - you can't say so from this node. extra_params_json is merged into the request body and is your only lever, and whether a given extender reads a steering field at all is between you and muapi's docs. For directed continuations, a fresh Image-to-Video call with the previous clip's last frame as image_1 is often the more controllable move.