Writing edit prompts that Aleph 2 can follow, and keeping iteration cheap

Updated 2026-10-02

Aleph 2 (runway/aleph-2) edits a clip you already have. You send the clip as input_video_url and a prompt that describes the change, and you get back a modified version of the same clip. Because it transforms footage instead of inventing it, the prompt has a different job than in text-to-video. This page covers prompt patterns that follow from how the endpoint is documented, and a workflow that keeps iteration cost under control. It makes no claims about output quality; test on your own footage.

The request, and its fixed rules

curl https://videorouter.sh/api/v1/videos \
  -H "Authorization: Bearer llmr_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "runway/aleph-2",
    "prompt": "change the weather to heavy rain, keep the people and framing",
    "input_video_url": "https://example.com/source-clip.mp4"
  }'

• input_video_url is a single public URL, not an array, and the host must be able to fetch it. Expired signed links fail the job.
• A non-empty prompt is required.
• The input is capped at 30 seconds, and output length follows the input.
• The field is mutually exclusive with start_image_url and all reference arrays in the same call. You cannot supply a style image alongside the clip.

Since there is no separate duration field and no reference image, the prompt and the source clip are the only controls you have. That is why prompt discipline matters.

Pattern 1: one change per request

VideoRouter's own guidance for editing is to describe the change rather than the whole scene, and to keep one major change per request. Compare these:

The left column bundles several changes, so when the result is wrong you cannot tell which instruction caused it. The right column maps one request to one observable difference. Chain changes across successive requests, each starting from the previous output, if you need several.

Pattern 2: name the change, then name what stays

A reliable structure has two parts: a verb phrase for the edit, then a short preservation clause. For example: "Replace the car with a red pickup truck. Keep the street, the pedestrians and the camera movement the same." The preservation clause is not a guarantee; it is a statement of intent you can compare against the output. Naming the subject of the edit (the car, the sky, the jacket) is more useful than abstract words like "improve" or "enhance".

Pattern 3: describe the target state, not the process

Write what the frame should contain after the edit ("the sky is overcast with heavy rain") rather than a procedure ("first darken the sky, then add drops"). One sentence in the present tense is easier to compare against the result than a multi-step instruction.

Pattern 4: avoid fields that do not apply

Do not try to control length, resolution or a start frame in the prompt or the request. Output length follows the input, so trim the source instead. If you want a new clip that reuses a character or motion from existing material, that is a different mode, reference-to-video, on models that support it; see the editing options comparison for how the modes differ.

Controlling iteration cost

Aleph 2 is billed by input duration, once at creation, and there is a per-request minimum charge, so very short clips are not proportionally cheaper. Polling is free and a job that fails upstream is not billed. With those mechanics, a cheap iteration loop looks like this:

1. Trim first. Cut the source to the shortest segment that contains the thing you are editing. Seconds you do not need are seconds you pay for.
2. Test the prompt on a short excerpt. Run the edit on a few seconds that include the subject. Change one variable between attempts: the verb, the target, or the preservation clause.
3. Record each attempt. Store the prompt, the source URL, the job id and your verdict. Without a log you will repeat prompts you already tried.
4. Run the winning prompt on the full clip. Only then pay for the long input.
5. Never resubmit a slow job. A second submission is a second charge; keep polling the same id.

For source material longer than 30 seconds, split it into segments, apply the same prompt to each, and stitch the results. Keep the prompt identical across segments so the edit is applied consistently, and expect to check seams yourself.

Sending several variations at once

PROMPTS = [
    "change the weather to heavy rain, keep the people and framing",
    "change the weather to heavy snow, keep the people and framing",
]
for p in PROMPTS:
    r = requests.post(f"{BASE}/videos", headers=H, json={
        "model": "runway/aleph-2",
        "prompt": p,
        "input_video_url": SOURCE,
    })
    print(p, r.status_code, r.json().get("id"))

Each call is billed separately, so run variations on the short excerpt, not the full clip. The rate for this model is on its page and the live table covers Runway rows:

No matching models in the live catalog right now.

Pitfalls

• A source URL that is private, expired or too slow to fetch fails the job. Test the URL in a fresh session first.
• Estimating cost from the clip length you hope to keep, rather than the input length, underestimates the bill.
• Do not assume an edit will leave everything else untouched; compare the output against the source on your own footage.
• Check what you got back before processing a library, since resolution and orientation fields are not editable here.

The Aleph 2 guide has the limits in short form, and the Python tutorial has a polling client you can reuse. See the model page for hosts, or create a key to try your first edit.

Frequently asked questions

Keep reading

• Editing Video with Runway Aleph 2 over API — Request Format and Limits
• Runway Gen-4.5 API Guide: Text & Image-to-Video Examples
• Runway vs Kling vs Veo API: How to Choose Between Them
• Video-to-Video Editing API Options: Aleph 2 and Alternatives