arkennemasis fal · Flux 3 First Last Frame to Video · $0.17-0.29/s

This is the interpolation trick, and it's the most controllable way to get video out of a generator. You supply the first frame and the last frame - both of which you rendered, retouched and approved - and the model fills in the motion that connects them. No inventing where the camera goes, no hoping the character's face stays put between shots. Two endpoints and a path.

ArkFal_blackforestlabs_flux_3_first_last_frame_to_video is that node: FLUX 3 Video on fal, $0.17/s at 720p, $0.29/s at 1080p, with native synchronized audio. And since FLUX 3 is early-access API with private weights - the open Dev backbone is still unshipped - fal is the only door.

What you set

• start_image - required. The first frame.
• end_image - required. The last frame. Both get checked for format and uploaded to fal's CDN free before anything is billed.
• prompt - how to get from one to the other. Describe the motion and the physical turn of events, not the pictures.
• duration - defaults to 5, and there is no auto here. That's deliberate: the model has to know how many seconds it has to travel from frame one to frame N. Pin it, and pin it to something physically plausible. A costume change in two seconds is going to look like a costume change in two seconds.
• resolution - 720p (default) or 1080p. The cheapest meaningful dial on the node.
• generate_audio - on by default and free either way; many shots want ambience rather than a music bed you'll add later anyway.
• aspect_ratio - auto, or forced if your two frames disagree with your target shape.
• safety_tolerance - 0 to 4, default 2.

Optional shared controls: max_cost_usd (default $20, checked before upload - set it to $3 and a greedy duration can't surprise you), reuse_identical_run (on by default), extra_json, max_concurrent.

Outputs: video, video_path, seed, info.

Why not just animate frame one

Because the end frame is a promise, and the model can't break it. Image-to-video gives the model one constraint and a lot of freedom; first/last gives it two constraints and a corridor. For product shots, transitions between two pose references, logo reveals, or any shot where the final composition matters, that's not a small difference - it's the difference between usable and "try again".

The cost, of course, is that you now need two good frames instead of one. In practice you generate the second frame with an edit model (Qwen Image Edit, or FLUX's own), which is where the rest of this pack's image nodes come in handy.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Hishamahmer/comfyui-arkennemasis

Restart, or install via ComfyUI Manager (search arkennemasis). Then your fal key:

FAL_KEY=your-key-from-fal.ai/dashboard/keys

in the .env next to run_nvidia_gpu.bat (or in ComfyUI/). No key widget on the node - the key stays in that file and out of your shared workflows. Nothing to download; there is no FLUX 3 checkpoint to install.

Where people get burned

Duration is the one. 5 is chosen for you and it's a short shot; if your two frames imply a bigger move, the model will either rush it or smear. Bump the duration instead of rewriting the prompt.

Second: both frames should be compatible. Different aspect ratios, different lighting, different framing and you'll get a morph rather than a shot. The node will happily take the input; the render is where you find out.

Third: the draft version of this same node costs $0.06/s and returns a draft cache that draft_enhance can finish at $0.29/s. Two-frame shots are exactly where drafting pays - checking that the transition reads in six seconds of draft is a lot cheaper than checking it in six seconds of 1080p.

Files land in output/fal/blackforestlabs_flux-3_first-last-frame-to-video/, and every request is written to output/fal/_requests.jsonl. If the run dies, fal Recover Result collects the finished job by its request id for free.