Prompting Multi-Shot Sequences (Scene by Scene)

TL;DR: "Multi-shot" means three different things depending on the vendor. Kling and Runway ship it as a real request field, a boolean toggle or a typed shot array. LTX and Veo 3.1 get you a multi-shot result from one generation through careful prose, no field involved. Everything else needs separate generations, held together by a repeated style block and stitched afterward.

Type "multi shot ai video" into a search bar and you get a wall of listicles that treat the phrase as one feature everyone has, in roughly the same shape. They don't. Some vendors give you a request field that plans cuts for you. Some get you the same look through nothing but prose, inside one generation, because the model reads shot boundaries out of your sentences. And for a lot of what you actually want to build, say a character delivering two lines of dialogue in two different angles, no single generation call does it at all, no matter how the prompt is written. The honest post is the one that tells you which case you're in before you write anything.

Which vendors ship multi-shot as a real request field?

Two do, and they document it two different ways. Kling's 3.0 and 3.0 Omni text-to-video endpoint exposes settings.multi_shot as a boolean with a default of true, and pairs it with a documented shot grammar in the prompt field itself. Kling's own API reference documents the syntax directly: the prompt field can carry "shot n, m, words; shot n, m, words;", separated by standard semicolons, where n is the "shot sequence number (1–6 shots supported)", m is the "shot duration in seconds (each shot ≥ 1s; sum of all shot durations must equal the total video duration)", and words is the "shot prompt (max 512 characters)". Read another way, settings.multi_shot alone does very little: set it false and the same shot-list prose gets ignored, while the shot grammar is what actually plans the cuts, gated behind that boolean.

Kling's VIDEO 3.0 user guide names the two modes this toggle unlocks, Multi-Shot and Custom Multi-Shot, and states that "multi-shot video generation can be triggered through two modes", and that enabling the first "is a prerequisite for enabling" the second. Leave it on with no per-shot detail and the guide says the model "will generally follow the prompts." However, it adds, "if the described scene is better suited to a single shot, the model will flexibly adjust based on the situation." Add the shot grammar under Custom Multi-Shot and the same guide states: "The model will strictly follow the prompts to generate a multi-shot video that meets your expectations." Automatic is a suggestion; custom is closer to a contract. Kling's own quickstart index also states plainly that once the toggle is off, "the model will default to generating a single-shot video". It is not cosmetic.

Runway's version is a different shape entirely: a dedicated recipe endpoint rather than a flag on the base model. POST /v1/recipes/multi_shot_video is described in Runway's own API reference as generating "a multi-cut video from a story prompt (auto mode) or a custom shot list (custom mode)." Auto mode takes one prompt field, and the reference states plainly that "auto decomposes a story prompt into exactly 5 shots": you write the story, Runway breaks it into cuts. Custom mode inverts that: you supply shots, which Runway types as "(array of object, required) — min 3 items; max 5 items." Each shot is its own object, with a prompt (max 512 characters) and duration (integer, 1 to 15), and the reference states the same constraint Kling has under a different name: "Per-shot durations must sum to duration." One call, one returned video, a typed schema instead of a string grammar to get it.

Here is Kling's Custom Multi-Shot request, built from the documented grammar rather than copied from any showcase example:

curl --location 'https://api-singapore.klingai.com/text-to-video/kling-3.0' \
  --header 'Authorization: Bearer {apikey}' --header 'Content-Type: application/json' \
  --data '{
    "prompt": "shot 1, 4, wide shot of a locksmith unlocking a shop front at dawn; shot 2, 5, medium shot of her flipping the sign to open; shot 3, 6, close-up of her hands sorting keys behind the counter.",
    "settings": {
      "resolution": "1080p", "aspect_ratio": "16:9",
      "duration": 15, "audio": "off", "multi_shot": true
    }
  }'

And Runway's custom mode, with the schema doing the work a string grammar does on Kling:

{
  "mode": "custom",
  "version": "2026-06",
  "duration": 15,
  "ratio": "1920:1080",
  "shots": [
    { "prompt": "Wide shot of a locksmith unlocking a shop front at dawn.", "duration": 4 },
    { "prompt": "Medium shot of her flipping the sign to open.", "duration": 5 },
    { "prompt": "Close-up of her hands sorting keys behind the counter.", "duration": 6 }
  ]
}

How do you write multiple shots into one prompt when there's no field for it?

By naming the cut in prose and re-establishing everything the previous shot doesn't carry forward, and two vendors document this as a real technique, not a workaround. LTX-2.5's own model page lists "native multi-shot scenes" as a headline capability and defines it directly: "Native multi-shot means a single generation can produce multiple connected shots, holding character, scene, lighting, visual style, and voice consistent across cuts." There is no boolean for it anywhere in LTX's request body: no multi_shot field, no shots array. The entire mechanism lives in how you write the prompt.

LTX's prompting guide is specific about that mechanism: "LTX-2.5 can also generate multi-shot scenes: several distinct shots joined by explicit cuts inside one prompt." Its instruction for writing one: "Write the full scene as one chronological paragraph (or a short sequence of sentences)." A numbered shot list is out, it says, "unless you also name the cut in prose." It also caps your ambition: "Prefer 2–4 shots in one generation; more cuts usually need clearer, shorter beats per shot." Most useful is what it says belongs at every cut: "Re-establish the new shot — shot scale, camera angle, who or what is in frame, and lighting if it changed." Keep identity consistent, it adds, by reusing "the same visual identifiers for recurring people or objects", and state whether the audio "continues across the cut" or drops. Nothing here is a field. It's a checklist for the sentence you write at every transition.

A wide shot frames a locksmith unlocking a shop front at dawn, cold blue
pre-sunrise light, the street empty. A hard cut transitions to a medium
shot of the same locksmith — grey work jacket, keys on her belt — flipping
the OPEN sign in the window, now lit by warm interior light spilling onto
the sidewalk. The street ambience continues across the cut, footsteps and
a distant bus. The shot cuts again to a close-up of her hands sorting brass
keys on the counter, same warm interior light, quieter now, just the
clink of metal.

Google's Veo 3.1 documents the same idea under a different name and a stricter syntax. The Cloud blog's "Workflow 3: Timestamp prompting" states: "This workflow allows you to direct a complete, multi-shot sequence with precise cinematic pacing, all within a single generation. By assigning actions to timed segments, you can efficiently create a full scene with multiple distinct shots, saving time and ensuring visual consistency." The worked example tags each beat with a timestamp range rather than naming the cut in a sentence:

[00:00-00:02] Wide shot of a locksmith unlocking a shop front at dawn,
cold pre-sunrise light on an empty street.
[00:02-00:05] Medium shot of the same locksmith flipping the OPEN sign,
warm interior light now spilling onto the sidewalk.
[00:05-00:08] Close-up of her hands sorting brass keys on the counter,
same warm light, quieter.

OpenAI documents a looser version of the same choice for Sora, and states outright that it is your call whether the result stays one clip or becomes several: "Describing multiple shots in a single prompt is also valid if you need to cover a sequence. When you do this, keep each shot block distinct: one camera setup, one subject action, and one lighting recipe at a time. This gives you flexibility to generate short standalone clips or longer, continuous moments, depending on your project. Treat each shot as a creative unit, and you can either stitch them together in an edit or let them play out as a sequence in one go." None of Kling, LTX, Veo, or Sora agree on notation: a shot grammar, a chronological paragraph, timestamp brackets, or plain prose. Pick the one the vendor you're calling actually documents, and don't carry Kling's semicolons into a Veo prompt expecting the same result.

When do you actually need separate generations, stitched afterward?

When the vendor has no single-call mechanism at all for what you're describing, most often two characters trading dialogue across a reverse angle, or a sequence longer than any one model's duration cap. Google documents this case explicitly rather than pretending its timestamp technique covers everything. The Cloud blog's Workflow 2, building a dialogue scene with ingredients to video, runs two entirely separate generation calls: one prompt producing the detective's line, a second separate prompt producing the woman's reply, held together only by feeding both calls the same reference images of the characters and the office setting. The guide calls the result "a multi-shot scene with consistent characters engaged in conversation," but nothing about the two generations is shared except the images you supplied to both.

OpenAI documents an equivalent path for Sora, at larger scale: its Batch API is recommended specifically for this. "Use the Batch API when you need to queue many video renders for offline processing, review pipelines, or studio workflows." Each line in the batch file carries the same request body a single call would, "which makes it a good fit for shot lists and scheduled render queues." Each line is a complete, independent POST /v1/videos call:

{"custom_id":"shot-001","method":"POST","url":"/v1/videos","body":{"model":"sora-2-pro","prompt":"Wide shot of a locksmith unlocking a shop front at dawn, cold pre-sunrise light.","size":"1920x1080","seconds":"8"}}
{"custom_id":"shot-002","method":"POST","url":"/v1/videos","body":{"model":"sora-2-pro","prompt":"Close-up of the same locksmith's hands sorting brass keys on the counter, warm interior light.","size":"1920x1080","seconds":"8"}}

Sora's own API is scheduled to leave entirely soon after this is published. OpenAI's deprecations page states it "notified developers using the Videos API and Sora 2 video generation model aliases and snapshots of their deprecation and removal from the API on September 24, 2026." If you're building a batch shot-list pipeline against sora-2 today, that date is closer than most production timelines.

Two things carry the weight when you stitch separate calls together, and neither is a parameter: the reference images or character description you repeat into every call, and the same continuity checklist LTX documents for cuts inside one generation: re-establish framing, keep identifiers consistent, and say explicitly whether sound continues. A stitched sequence has no vendor enforcing that for you across calls; a single-generation multi-shot at least has the model holding its own continuity, badly or well.

Building the piece that actually reuses: a style block plus one prompt per shot

The mechanism changes by vendor. What doesn't need to change is how you write the parts that repeat. Every technique above, Kling's grammar, Runway's array, LTX's prose, Veo's timestamps, or Sora's separate calls, asks you to restate the same character, wardrobe, and lighting language at every shot boundary. Writing that fresh each time is where sequences drift: the jacket becomes "grey" in shot one and "charcoal" in shot three because you typed it twice from memory.

The fix is mechanical, not creative: write the identity and look once, as a block, and paste it, unedited, into every shot.

STYLE BLOCK (reuse verbatim in every shot):
Subject: a locksmith in her 40s, grey work jacket, keys on a leather belt,
hair tied back. Lighting: cold blue pre-dawn exterior shifting to warm
tungsten interior once she's inside. Palette: desaturated blue exteriors,
amber interiors. Grain: light 35mm-style texture, no digital sharpness.

SHOT 1: [STYLE BLOCK] Wide shot, she unlocks the shop's front door,
street empty.
SHOT 2: [STYLE BLOCK] Medium shot, she flips the OPEN sign, now lit by
interior tungsten spilling onto the sidewalk.
SHOT 3: [STYLE BLOCK] Close-up, her hands sorting brass keys on the
counter.

That block is what turns "one prompt per shot" from three separate guesses into one sequence. It is also exactly the layer a prompt manager is for: store the style block once with the variables marked, fill [SUBJECT], [LIGHTING], and [PALETTE] per project, and generate each shot from the same source instead of retyping it into whichever vendor's box you're calling that day. Video prompt generation sits on the Advanced and Team plans rather than Pro, and the free plan includes 5 prompt enhancements per day, forever, per our FAQ.

If you're deciding which model to build a sequence around in the first place, Veo 3 vs Sora vs Kling covers the tradeoffs, AI video duration parameters by model covers exactly how much total time you're budgeting across those shots, and planning a 15-second shot in Kling 3.0 goes deeper on the arithmetic behind Kling's specific cap. If the sequence spans more than one model, say reference images from Gemini feeding a Veo generation, multi-modal prompting with Gemini covers where those surfaces disagree on what they'll accept.

One closing honesty note. We build the prompt and the reusable library around it. We do not generate the video ourselves, and every field, endpoint, and quote above belongs to Kling, Runway, LTX, Google, or OpenAI, read from their own documentation on September 3, 2026. Panels change faster than articles do, so confirm the live request schema before you ship a pipeline on any of it.