How to Prompt Luma Ray 3.2

TL;DR: Luma Ray 3.2, announced 9 June 2026, is Luma's current video model. Text-to-video and image-to-video produce 5-second or 10-second clips at 360p to 1080p in six aspect ratios, with no natively generated audio. Prompts run to 6,000 characters. There is no negative prompt and no seed.

How do you prompt Luma Ray 3.2?

You prompt Ray 3.2 by deciding which of its four workflows you are in first, then writing to that workflow's constraints. Luma's Ray page describes Ray3.2 as powering "four workflows in one: Modify Video, image2video, text2video, and Reframe" (lumalabs.ai/ray, accessed 26 August 2026). Those four take very different prompts.

For text-to-video, the Luma Agents documentation gives one line of official guidance on the prompt field: "A text description of the video, 1 to 6,000 characters. Be specific about subject, motion, camera movement, lighting, and pacing" (Video generation, accessed 26 August 2026). That is the whole published instruction. Luma ships a detailed prompting guide for its image model, Uni-1, but as of today there is no equivalent prompting guide for Ray 3.2 in the Agents docs.

For Modify Video, the advice inverts. Luma's own learning-centre article says the prompt "describes the target end state" and "should not describe a sequence of changes or a story over time," because the model already has timing and motion from your source clip (Ray3.2 Introduction & Core Concepts, 27 May 2026, accessed 26 August 2026).

So there is no single Luma prompt formula. There is a workflow question, and then a set of hard limits that decide what your prompt is even allowed to ask for.

What can Ray 3.2 actually output?

Four resolutions, two clip lengths, six aspect ratios. Here is the published surface, taken from the Agents API video generation guide and cross-checked against the Ray product page FAQ.

That last pair matters more than it looks. Without a seed, you cannot re-run a shot you liked. Without a negative prompt, "no lens flare" is not a supported instruction, it is just more text describing a lens flare. Luma's guidance for its image model applies here too: describe what you want, positively.

The frame grid is the quietly useful number. Because Ray 3.2 works on a 24fps output grid, a beat two seconds into a five-second clip is frame 48, and you can pin an image there. That is the difference between asking for a change and scheduling one.

Does Luma Ray 3.2 have native audio?

No, not on the two generation paths. Luma answers this in its own words on the Ray page FAQ: "text2video and image2video: No, there's no natively-generated audio, so voiceover, music, and sound effects are added as a separate step. Modify Video and Reframe will preserve your original audio" (accessed 26 August 2026).

The API documentation agrees by omission. Across the video generation guide, the video editing guide, the models page, the pricing page and the full API reference, the word "audio" does not appear once. There is no audio parameter, no dialogue field, no sound-effect control.

This is the single biggest thing to internalise before you write a Ray 3.2 prompt. Writing dialogue into the prompt does not produce dialogue. Describing "the crunch of gravel underfoot" buys you the visual of gravel, not the crunch. Luma's own product framing supports this: its LLM information page lists ElevenLabs SFX, Music and v3 as audio models integrated into Luma plans, which is a fairly direct statement that Ray does not make the sound itself.

If you are used to writing sound into a prompt because Veo 3.1 rewards it, you will need a different habit here. Our Veo 3.1 dialogue prompting guide covers the model where that habit belongs.

What does a good Ray 3.2 text-to-video prompt look like?

Follow the four things Luma names in its own parameter description: subject, motion, camera movement, lighting and pacing. Then stop. Ray 3.2 is not rewarded for keyword stuffing, and the ceiling is a shot, not a scene.

Here is a prompt template that maps directly onto the published guidance:

[SUBJECT + what it is doing]
[MOTION: how the subject moves, at what speed]
[CAMERA: shot size, lens feel, and the one move the camera makes]
[LIGHTING: source, direction, quality, time of day]
[PACING: what the five seconds should feel like]

Filled in, for a five-second widescreen shot:

A ceramicist's hands centring wet clay on a spinning wheel, grey slip running
over her knuckles.
Motion: the wheel turns steadily, her thumbs press inward once and the wall of
the pot rises.
Camera: tight overhead shot, one slow push in, single continuous take.
Lighting: single north-facing window camera-left, soft falloff, overcast
daylight, deep shadow in the studio behind.
Pacing: one unhurried action held for the full five seconds.

The API request that carries it:

{
  "model": "ray-3.2",
  "type": "video",
  "prompt": "A ceramicist's hands centring wet clay on a spinning wheel...",
  "aspect_ratio": "16:9",
  "video": {
    "resolution": "1080p",
    "duration": "5s"
  }
}

Three habits are worth building.

Ask for one beat, not three. Five seconds at 24fps is 120 frames. A prompt that asks for a character to enter, react and leave will get you a smeared compromise. If you need three beats, that is what keyframes are for.

Name the camera move once. "Slow push in" is a direction. "Dolly in while craning up and whipping left" is a request for the model to pick one and ignore the rest.

Do not write your negatives. There is no negative prompt. "No text, no watermark, no extra fingers" adds tokens describing text, watermarks and fingers. If something keeps appearing, change the positive description of the frame instead.

If you want the vocabulary for the camera and lighting lines, how to direct AI video like a filmmaker is the reference we point people at.

How do keyframes change the prompt?

They demote it. This is the most important structural fact about Ray 3.2 and the one most guides miss.

Luma's controls article says it plainly: "with this system, especially when you're using multiple keyframes, your settings often matter more than your prompt. The model is good at inventing a believable look on its own to bridge your keyframes; the controls are what hold it to your footage" (Ray3.2 Controls & Workflows In Depth, 3 June 2026, accessed 26 August 2026).

On the API, multi-keyframe image-to-video takes two parallel arrays under video: keyframes, a list of guide images, and keyframe_indexes, the output-frame positions where each one is pinned. The documentation is specific that these are positions in the duration × 24fps grid, so a 5s clip accepts indexes 0 to 120 and a 10s clip accepts 0 to 240. The arrays must be the same length, and providing one without the other returns a 400.

{
  "model": "ray-3.2",
  "type": "video",
  "prompt": "A hot-air balloon drifts across the valley as the sun rises",
  "aspect_ratio": "16:9",
  "video": {
    "resolution": "720p",
    "duration": "5s",
    "keyframes": [
      { "url": "https://example.com/launch.jpg" },
      { "url": "https://example.com/midflight.jpg" },
      { "url": "https://example.com/sunrise.jpg" }
    ],
    "keyframe_indexes": [0, 60, 120]
  }
}

Two constraints to hold in your head. keyframes is mutually exclusive with start_frame, end_frame and loop, because a single keyframe at index 0 is the same thing as a start frame. And Luma notes that the multi-keyframe route runs the full Ray 3.2 path, which lifts the restrictions the older anchor pair carries: with keyframes you can use 10s and hdr: true, neither of which is allowed with start_frame or end_frame.

When you are keyframing, rewrite the prompt to describe the connective tissue, not the beats. The beats are already images. The prompt's job is the world between them.

How do you prompt Modify Video, the video-to-video path?

Differently enough that the text-to-video advice actively hurts you.

Modify Video takes a source clip and returns the same clip re-imagined. Luma's learning-centre article states that output duration always matches source duration and that there is no duration parameter: "A 7.3-second source produces a 7.3-second output." So there is nothing to pace. The timing is already decided.

The article names three inputs: a required source video, plus a prompt and keyframes, of which you need at least one. Prompt alone gives a pure restyle. Keyframes alone give a reference-driven transformation. Both together is the strongest control, because the prompt sets creative intent while the keyframes lock specific moments.

Inside the Luma app, the conditioning controls are Motion and Structure, each on a 1 to 9 scale where 9 preserves most, plus Character locks for Faces, Bodies and Poses or Blocking. Luma's controls article flags that the Structure direction "was flipped recently, so if you're used to the older behavior, note that bigger numbers now mean a tighter hold on your footage."

The Agents API exposes a different vocabulary for the same idea. There, video.edit.strength takes nine preset values across three bands: adhere_1 to adhere_3, flex_1 to flex_3 with flex_2 named as a common default, and reimagine_1 to reimagine_3. There is also video.edit.auto_controls, which Luma calls the recommended default, and a manual video.edit.controls set covering pose, depth, normals, trajectory and face. Setting auto_controls: true alongside manual controls is rejected outright.

A Modify Video prompt that works looks like a look, not a script:

Restyle to hand-painted gouache animation. Visible brush texture on every
surface, slightly wobbling outlines, warm ochre and teal palette. Keep the
subject's face and expression. Replace the office background with a paper-
textured flat colour field.

Notice what is absent: no camera move, no "then she turns", no timing. All of that is coming from the source clip.

Where do Luma's own numbers disagree?

In several places, and if you have read a Ray 3.2 roundup that quoted a single confident figure, this is why it may be wrong. These are all live Luma pages, all fetched on 26 August 2026.

Luma's learning-centre article sides with the API on the keyframe count, saying Ray 3.2 supports "up to 64 keyframes at arbitrary source-frame indexes." So the marketing page and the app documentation say 16; the API docs and the deep-dive article say 64.

None of this means Luma is being careless. The most likely reading is that the app surface and the API surface ship on different schedules, and the marketing page describes the app. But it does mean one thing for you: the number that applies is the number on the surface you are actually using. If you are calling ray-3.2 over HTTP, the API docs win. If you are clicking in the Luma app, the Ray page wins. Test the ceiling before you build a pipeline on it.

The frame-rate detail is the one worth memorising. Luma's Ray FAQ publishes the Modify ceiling as a function of source frame rate: 24fps gives up to 20 seconds, 30fps up to 15 seconds, 60fps up to 7 seconds. Conform your source to 24fps before you upload and you get almost three times the usable clip length you would from 60fps footage.

How does Ray 3.2 compare with the other current video models?

Only on the specs that change how you write the prompt. Everything below is from each vendor's own documentation, checked on 26 August 2026.

Three notes on that table, because the cells matter more than the shape.

Google now names a default. Google's Gemini API video documentation says: "Use Gemini Omni Flash as your default model for video generation," and recommends Veo 3.1 for scene extension, last-frame control or legacy pipelines. Both are labelled preview in Google's own docs; the model ids are gemini-omni-flash-preview and veo-3.1-generate-preview. Omni Flash's model card lists output video as 3s to 10s at 720p, 24 FPS, and its guide states the model generates an audio track by default. Google's Veo guide describes 8-second videos at 720p, 1080p or 4k with natively generated audio, and its model-features table gives Veo 3.1 durations of 4, 6 or 8 seconds at 24fps, with 8 seconds required for 1080p or 4k and audio marked always on.

Kling's cells are mostly blank on purpose. Kling's developer documentation renders entirely client-side and returns no server-rendered spec text; a reader proxy returned 403. What I could read is Kling's own pricing data embedded in its release pages, which lists per-second rates for Kling 3.0 at 720P, 1080P and 4K, and distinguishes "No Native Audio" from "With Native Audio" rows. That is enough to fill two cells honestly. Clip length and frame rate are marked not published because I could not reach a Kling page that publishes them, not because Kling does not.

Ray 3.2 is the only one of the four with no native audio. That is not a criticism, it is a workflow fact. Luma's design centre of gravity is production video-to-video, HDR and EXR delivery, not one-shot social clips with sound. If you want a comparison written for that choice, Veo 3 vs Sora vs Kling covers the generation-first models, and why your AI videos look generic covers the failure mode all four share.

What is Ray 3.2 actually good at?

Transforming footage that already exists. Luma's own positioning is unusually clear about this, and it should change what you prompt for.

The learning-centre article calls Ray 3.2 "the production-grade V2V workhorse for transforming existing video while preserving the structure of the source," and lists the source material it wants: a steady or smoothly-moving camera, deliberate well-paced action, sharp in-focus and well-lit footage, and a single clear subject that reads distinctly from the background.

The failure list is just as specific. Luma's Ray FAQ says Modify Video "can struggle with footage which has heavy camera shake, whip-fast or chaotic action, blurry/dark/low-res footage, crowded overlapping subjects, and heavily occluded faces or bodies."

Two more published capabilities worth prompting around. Expressive Facial Performance "transfers the full expression state, for up to 8 faces." And lip sync survives a restyle, but conditionally: asked whether Modify Video preserves lip sync and dialogue timing, Luma answers "Yes, when Face tracking is on." If you restyle a talking-head clip with Face off, expect the mouth to drift.

For costing, Luma publishes both a credit table on the Ray page and dollar rates in the Agents pricing guide. On the API, a standard-dynamic-range 5-second clip runs $0.06 at 360p, $0.15 at 540p, $0.30 at 720p and $1.20 at 1080p; HDR is restricted to 720p and 1080p at 5 seconds and prices at $0.60 and $2.40, with HDR plus EXR at $0.90 and $3.60. Draft at 360p exists precisely so you can burn twenty cheap iterations before spending on the 1080p take.

The prompting checklist

Before you spend a 1080p credit, run these five checks.

1. Name the workflow. Text-to-video, image-to-video, Modify or Reframe. Each takes a different prompt, and Modify takes an end state rather than a sequence.
2. Check your length is legal. 5s or 10s on generation. On Modify, conform the source to 24fps first if you want the full ceiling.
3. Strip the audio language. No dialogue, no sound design, no music cues. They do nothing and they cost you tokens against the 6,000-character limit.
4. Delete the negatives. Rewrite each "no X" as a positive description of what should be in that part of the frame.
5. Save the exact prompt and settings. There is no seed. If you do not store the run, you cannot repeat it.

That fifth one is where most people quietly lose work. A shot lands, nobody writes down which Structure value or which prompt wording produced it, and a week later the same brief takes forty attempts.

That is the problem Prompt Architects is built for, and it is worth being precise about what we do and do not do here. We do not generate video. Ray 3.2, Veo, Kling and Omni Flash generate video. What we do is turn a rough idea into a structured video prompt with the shot, motion, camera, lighting and pacing slots filled in, then keep the versions that worked in a library you can search, with variables for the parts that change per client or per shot. If you are running the same commercial across six markets, that is the layer that stops each market being a fresh guess.

There is a free plan, so you can test whether the structured version of your prompt actually outperforms your current one before paying for anything. Current pricing is on the pricing page.