Camera control JSON is the cleanest way to make an AI film move with intent. Rather than coaxing a video model with a paragraph of adjectives, you declare the move once in a structured field on the shot and let the platform translate it into whatever dialect the rendering model speaks. In CoreReflex that field is spec.camera, and it routes two ways, a natural-language clause for Veo and a structured camera_control object for Kling, so the same board produces the same motion no matter which model draws the frame.
Why camera moves belong in the shot spec
When the agentic Director boards a film, every shot is a small contract: a role (establishing, insert, hero, transition), a prompt describing what's in frame, and a camera move describing how the lens behaves. The first two translate cleanly into language. The camera move is where things get slippery, because the two strongest video models on the stack interpret motion in completely different ways. Veo reads natural language and infers movement from phrasing. Kling exposes a dedicated camera_control object with explicit parameters.
If you hand-author the move into each model's preferred format, your shots stop being portable. Swap the assigned model and the motion drifts, or vanishes. Worse, prompt-only camera direction is unreliable on its own: "slow push-in" buried in a sentence competes with every other adjective for the model's attention, and the result is inconsistent from shot to shot.
Putting the move in spec.camera solves both problems. You describe intent once, in a structured, model-agnostic shape, and the platform compiles it down to the target. It's the same principle that lets CoreReflex treat the entire edit as data: structure first, rendering second.
How spec.camera routes to Veo and Kling
A camera move in the spec is a small object, readable at a glance, diffable in version control. A slow push-in looks like { "move": "dolly", "direction": "in", "speed": "slow" }. From there, routing depends on which model is assigned to the shot.
The Veo path: a deterministic prompt clause
Veo doesn't accept a structured camera object, so spec.camera compiles into a consistent natural-language clause appended to the shot prompt. { "move": "dolly", "direction": "in" } becomes phrasing like "slow dolly-in toward the subject." The advantage is determinism: instead of each shot inventing its own wording for the same move, the platform emits the same vetted phrasing every time, exactly what you want when a film has a dozen shots that all need to feel like one camera operator shot them.
The Kling path: a structured camera_control object
Kling exposes a real camera_control API with explicit fields for horizontal and vertical movement, pan, tilt, roll, and zoom. Here spec.camera maps straight onto those parameters, no prose, no interpretation layer, nothing lost in translation. A push-in becomes a zoom or dolly value; a reveal becomes a horizontal translation. Because the mapping is structured on both ends, the move you boarded is the move you get.
Neither path is "better." The point is that you author once and the platform owns the translation, so you can reassign a shot from one model to another without rewriting your boards.
The camera fields you can set
The vocabulary mirrors how a real camera moves on set. You combine a move with a direction and an intensity, and the platform resolves the rest against the target model.
| Field | Example values | What it does |
|---|---|---|
move | dolly, truck, pedestal, pan, tilt, zoom, orbit, handheld, static | The class of motion |
direction | in, out, left, right, up, down | Which way the move travels |
speed / intensity | slow, medium, fast (or 0–1) | How aggressive the move is |
subject | optional anchor | What the move is relative to |
A static shot is a first-class choice, not the absence of one: { "move": "static" } tells the model to hold the frame, which keeps inserts and text cards from wobbling. Keep moves purposeful, one clear move per shot reads far better than a camera trying to do everything at once.
Because the move lives in data, you can define a house style once and reuse it. If your brand's explainers always open on a slow push-in and cut on a hold, that's two reusable camera objects you drop into every board, the same way you'd drive the editor programmatically instead of nudging sliders by hand.
Common moves and when to reach for them
- Static hold, inserts, lower-thirds, anything that has to read. Stillness is a feature.
- Slow dolly-in, build intensity on a subject or a product.
- Dolly-out or pull-back, reveal context the audience didn't know was there.
- Pan or tilt, follow action, or scan across a scene at a steady pace.
- Orbit, show a product in the round when one angle won't sell it.
- Handheld, inject energy and immediacy into a moment that should feel live.
Camera moves, continuity, and the quality gate
A camera move never lives in isolation. CoreReflex anchors continuity by feeding the last frame of one shot into the next, so a push-in that ends on a tight close-up hands that framing to the following shot, your cuts stay continuous instead of jumping. Planning the camera in the spec is also planning how shots hand off to one another.
Motion is one of the things the quality gate scores. Every generated shot runs concrete checks, prompt match, sharpness, motion coherence, on-screen text legibility, on-brand, claims-risk, and a move that smears, warps, or stutters fails the motion-coherence check. Failures trigger selective regeneration: the platform re-rolls the offending shot rather than restarting the whole film. So a camera move isn't just an instruction, it's something the system verifies actually rendered the way you asked.
Every render also carries a portable trace of the model, prompt, parameters, and score, which makes your camera spec reproducible. Replay the trace and you get the same move, the same framing, the same result.
Calling it from the API, SDK, and MCP
You can set spec.camera anywhere you build shots. Planning, scoring, and editing are free, only generation spends credits, so you can iterate on boards and camera moves as much as you like before you ever render.
- REST API and SDK, set the camera field as you assemble each shot. The SDK quickstart walks through your first render end to end, and the full reference lives in the API documentation.
- MCP, if an AI agent is doing the boarding, it sets
spec.camerathe same way through the MCP server, so an autonomous workflow can choose camera moves shot by shot.
Whichever surface you use, the contract is identical: one structured field, two rendering paths, one consistent result.
Frequently asked questions
How do I specify a camera move in the API?
Set the spec.camera field on the shot to a small object describing the move, direction, and intensity, for example { "move": "dolly", "direction": "in", "speed": "slow" }. You don't pick a model-specific format; the platform compiles your spec into a Veo prompt clause or a Kling camera_control object depending on which model renders the shot.
Does the camera spec work with both Veo and Kling?
Yes. The same spec.camera routes two ways, it compiles to a deterministic natural-language clause for Veo and maps directly onto Kling's structured camera_control parameters. You author the move once and reassign models without rewriting it.
What happens if a model doesn't support a specific move?
The platform resolves your spec to the closest motion the assigned model can express, and the motion-coherence check in the quality gate flags shots where the result doesn't hold together, so a poorly translated move tends to fail and regenerate rather than slip into the final cut.
Are camera moves reproducible?
They are. The camera spec is part of the portable trace stored with every generation, alongside the model, prompt, and parameters. Replay the trace and the same move renders the same way, which makes camera decisions auditable and repeatable.
Board your next shot with the camera in the data
Camera control JSON turns motion from a prompt-engineering guessing game into a structured decision you make once and reuse everywhere, verified by the quality gate, anchored by continuity, and replayable from the trace. Browse more developer guides to see how the rest of the shot spec fits together, then start free with no credit card and board your first moving shot.