FLUX Video Edit [fast]

Introduction

A finished clip is expensive to throw away. The shot is framed and the performance landed, and one thing in it is wrong: a jacket in the wrong color, a bottle carrying last season's packaging, a wall that clashes with the brand palette. Regenerating the whole shot to fix that one thing gives you a different shot.

FLUX Video Edit [fast] takes the clip you already have and changes only what you name. There is no mask to paint, no keyframe to place, and no reference to supply. You pass a video and a sentence.

Five words changed the jacket. Her hair, the white top underneath, the gray backdrop, the shadow on the floor, the speed of the turn and the moment she settles are all still the source's. This guide covers the request, what the source clip fixes for you, how to write an instruction the model can act on, and how to run several edits without losing the shot.

The request

An edit takes two required fields: the clip in inputs.video and the instruction in positivePrompt.

import { createClient } from '@runware/sdk'

const client = await createClient({ apiKey: process.env.RUNWARE_API_KEY })
await client.connect()

const [result] = await client.run({
  model: 'bfl:flux@video-edit-fast',
  positivePrompt: 'Make the denim jacket deep burgundy.',
  inputs: {
    video: 'https://vm.runware.ai/video/os/a14d18/ws/2/vi/1b9e4c37-5a82-4d60-b3f1-7c2a9e5d8410.mp4'
  },
  deliveryMethod: 'async'
})

import asyncio
import os

from runware import Runware


async def main():
    async with Runware(api_key=os.environ["RUNWARE_API_KEY"]) as client:
        results = await client.run({
            "model": "bfl:flux@video-edit-fast",
            "positivePrompt": "Make the denim jacket deep burgundy.",
            "inputs": {
                "video": "https://vm.runware.ai/video/os/a14d18/ws/2/vi/1b9e4c37-5a82-4d60-b3f1-7c2a9e5d8410.mp4"
            },
            "deliveryMethod": "async"
        })


asyncio.run(main())

curl https://api.runware.ai/v1 \
  -H "Authorization: Bearer $RUNWARE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '[
    {
      "taskType": "videoInference",
      "taskUUID": "a7c4e918-2d63-4b05-9e71-3f8a2c6d1b40",
      "model": "bfl:flux@video-edit-fast",
      "positivePrompt": "Make the denim jacket deep burgundy.",
      "inputs": {
        "video": "https://vm.runware.ai/video/os/a14d18/ws/2/vi/1b9e4c37-5a82-4d60-b3f1-7c2a9e5d8410.mp4"
      },
      "deliveryMethod": "async"
    }
  ]'

runware run bfl:flux@video-edit-fast \
  positivePrompt="Make the denim jacket deep burgundy." \
  inputs.video=https://vm.runware.ai/video/os/a14d18/ws/2/vi/1b9e4c37-5a82-4d60-b3f1-7c2a9e5d8410.mp4 \
  deliveryMethod=async

{
  "taskType": "videoInference",
  "taskUUID": "a7c4e918-2d63-4b05-9e71-3f8a2c6d1b40",
  "model": "bfl:flux@video-edit-fast",
  "positivePrompt": "Make the denim jacket deep burgundy.",
  "inputs": {
    "video": "https://vm.runware.ai/video/os/a14d18/ws/2/vi/1b9e4c37-5a82-4d60-b3f1-7c2a9e5d8410.mp4"
  },
  "deliveryMethod": "async"
}

[
  {
    "taskType": "videoInference",
    "taskUUID": "a7c4e918-2d63-4b05-9e71-3f8a2c6d1b40",
    "videoUUID": "6d2f8a51-9c34-4e70-8b16-2a7c5d1f9e83",
    "videoURL": "https://vm.runware.ai/video/os/a14d18/ws/2/vi/6d2f8a51-9c34-4e70-8b16-2a7c5d1f9e83.mp4"
  }
]

inputs.video takes a URL or the UUID of a video from an earlier task, which is what makes an edit cheap to bolt onto a generation you just ran: pass the videoUUID you got back rather than downloading and re-uploading the file.

There is no third thing to configure. No width, no height, no duration, no resolution, no frame rate, no seed. The only optional model-specific setting is settings.safetyTolerance, covered further down.

The source clip decides everything it can

Every property of the output that is not the edit itself comes from the file you sent:

• Duration is the source's, to the frame. There is no duration field to set and no way to lengthen or shorten a clip here.
• Aspect ratio is the source's. A 9:16 clip comes back 9:16.
• Resolution is the source's, up to a ceiling: anything above 720p is downscaled to 720p, and anything at or below it keeps its size.
• Frame rate is normalized to 24 fps whatever the source ran at.
• Audio is carried through untouched unless the instruction asks for a sound or dialogue change. A silent source returns a silent result.

The practical consequence is that your edit request cannot fix a framing problem. Reframing, cropping, slowing down, speeding up and extending are all jobs for a different task, and they belong upstream of this one.

Preservation is the default

This is the part that catches people arriving from other video editors, where the prompt has to pin down everything that must survive or the model quietly redecorates the shot. Here the opposite holds: everything the prompt does not mention stays as shot.

That makes most preserve clauses wasted characters, though not all of them. Both of these clips came from the same source, and only the first prompt is worth typing:

The long version lists twelve things the short version never put at risk, and it changes nothing. Global properties do not need protecting. The lighting, the camera, the framing and the timing are never candidates for an edit, so listing them is spent characters.

Objects are the exception, and it is a real one. Something sitting next to your target can be swept up with it, and whether it is depends on the run rather than the prompt. Naming the neighbors costs a clause and removes the coin flip:

• Do not preserve the shot. "Keep the lighting, the camera and the timing" protects things nothing was going to touch.
• Do preserve the neighbors. "The chrome faucet, the bowl of lemons and the stack of cookbooks all stay exactly as they are" protects objects a removal genuinely can take with it. Removing objects shows the same instruction losing a faucet without that clause and keeping it with one.

Naming the target

Preservation by default only helps if the model can tell which object you mean. Most disappointing edits are a pointer problem, not a capability problem, and they show up on frames with more than one plausible candidate.

This desk has a mug, a plant, a notebook and a pair of glasses on it. "Change the mug" is unambiguous about the noun and silent about everything else in the instruction, which leaves the model to invent what "change" means:

The second instruction carries three things the first does not: which object (the white ceramic one, to the right of the keyboard), what it becomes (a matte black stoneware mug), and by omission, that nothing about its placement should move. A useful shape to fall back on is what it is, where it is, what it becomes.

Two habits pay for themselves here:

• Point with the frame, not with the story. "The mug on the right of the keyboard" is a position the model can resolve. "The mug she was drinking from" is a fact about a shot the model did not watch you plan.
• Say the finished state, not the operation. "A matte black stoneware mug" describes an outcome. "Darken the mug" describes a slider, and the model does not have one.

Several edits at once

An instruction can carry more than one edit, and a request combining several is accepted. This clip takes an addition, a surface change and a lighting change together:

Write each edit as its own sentence. A comma-joined chain of instructions gives the model a parsing problem on top of an editing one, and the edit that goes wrong is usually the one that got attached to the wrong noun. Three short sentences read as three jobs.

Two edits should never share a prompt when they fight over the same pixels. Adding a lamp and setting the light that lamp casts is one change described twice, and asking for both invites the model to arbitrate.

Staging edits across runs

Black Forest Labs recommend applying edits in stages rather than putting every instruction in one request: run the first change, then feed that result back in and describe the next one. Because inputs.video accepts a videoUUID, staging costs nothing but the extra calls:

{
  "inputs": {
    "video": "6d2f8a51-9c34-4e70-8b16-2a7c5d1f9e83"
  }
}

Here is the lobby again, one edit at a time:

The end states are meant to be comparable, and the difference between the routes is what you get to inspect:

• Stage when the edits are unrelated in kind, when one depends on another landing first, or when a combined attempt dropped one of its instructions. You get a checkpoint between every change, and a failed step costs one run rather than the whole result.
• Combine when the edits are small, independent and already proven. One request and one bill, with no chance of a second pass disturbing the first because there is no second pass.

Staging is not free. Every pass re-encodes the whole frame, so small departures from the source accumulate: skin texture softens and fine background detail simplifies. Four passes of a change is four generations of drift on the parts you never wanted touched, which is the argument for keeping a chain short and for re-running from the original source rather than adding another pass to fix the last one.

Content moderation

settings.safetyTolerance controls how strictly the request is moderated, from 0 (strictest) to 4 (most permissive), defaulting to 2.

{
  "settings": {
    "safetyTolerance": 3
  }
}

Moderation runs on the instruction and on the source clip, so a rejection is not always about your words. An edit request against footage the moderator objects to fails whatever the prompt says. Raise the tolerance when legitimate commercial footage is being turned away, and lower it when you are running user-supplied prompts through the model and want the stricter gate.

Working without a seed

There is no seed on this model, so an edit cannot be reproduced. Running the same prompt against the same source twice gives you two similar and non-identical results.

Two working habits follow. Keep the file, not the recipe. The prompt that produced an approved clip will not produce it again, so the output is the artifact worth storing. And iterate on the shortest clip that shows the problem: billing is per second of output, so finding an instruction on a 4-second cut and running it once on the 15-second master is the difference between a cheap search and an expensive one.

Tips

1. Start with the shortest instruction that could work. Everything unmentioned is preserved, so extra words are extra surface for the model to act on. Add specificity when an edit misses, not before.

2. Name the object by what it looks like and where it sits. Appearance plus position resolves a target that a story-level description ("her mug", "the hero product") cannot.

3. Describe the finished state. The model renders outcomes, not operations. "A matte black stoneware mug" works where "darken the mug" asks for a control that does not exist.

4. Give each edit its own sentence. When a prompt does carry more than one change, sentence boundaries are what keep them from being read as one confused instruction.

5. Never combine edits that touch the same thing. Adding a lamp and setting the light it casts are one change, and splitting them into two instructions makes the model arbitrate.

6. Preserve objects, not the shot. Naming the props and fixtures near your target is worth typing, because a neighbor can be swept up with it. Naming the lighting, camera and timing is not, because nothing was going to touch them.

7. Stage unrelated edits across runs, and keep the chain short. Each pass re-encodes the entire frame, so the checkpoint you gain is paid for in drift on the parts you were protecting.

8. Stage from a videoUUID, not a re-upload. The output of one task is a valid input to the next with no download in between.

9. Find the instruction on a short cut. You pay per second of output, and prompt search is where the seconds pile up.

10. Archive the approved output. With no seed, the file is the only copy of that result you will ever have.