How to batch render an AI video story without losing the character

Batch rendering, in the vendor sense, usually means "upload a CSV, come back later, download MP4s." Fliki, Morphed, BlinklyAI, Google's Veo Batch API — the pitch is the same across all of them: queue work, parallelise, pick up the files tomorrow. That is a useful shape when you are rendering a hundred unrelated ad variants and you need volume. It is the wrong shape when you are rendering one six-scene story and the character has to be the same person in every scene.

The problem with "parallelise everything" on a story is that scene four needs to inherit from scene three, which only exists after scene three has rendered. A pure parallel queue produces six scenes of what is nominally the same person but drifts on the fourth clip because scene four was generated against the reference sheet and not against the last frame of what shipped. This is the practical limit of CSV-driven batch rendering on narrative work, and nobody writes about it because the batch tools are built for ads, not stories.

This piece is how we actually run a six-scene story as a queue: the hand-off that keeps the character locked, which engine takes which scene, and what the full-batch credit math works out to.

The reference chain, not the reference list

The move is to think of a story as a chain of references rather than a list of scenes.

Scene one's inputs: the character reference sheet, the identity prompt. Scene two's inputs: the reference sheet, the identity prompt, and the last frame of scene one. Scene three's inputs: the reference sheet, the identity prompt, and the last frame of scene two. And so on through scene six.

The reference sheet and the identity prompt are frozen. They do not change scene to scene. The variable is the handed-forward last frame, which is the piece that makes scene N feel like a continuation of scene N–1 rather than a cold render of a vaguely similar person. On the engines that take two-frame guidance (Veo 3.1 Fast, Kling O3 Pro, Seedance 2.5), the first frame of scene N is pinned to the last frame of scene N–1 before you touch the slider.

The chain forces a sequential queue on part of the batch. Scene one can render in parallel with scenes two through six only if you have pre-generated the first-and-last frames of every scene as stills. If you have, the chain is actually a wide pass of stills followed by a wide parallel pass of videos — which is the shape batch rendering is actually good for.

The two-pass batch

Pass one, cheap and parallel: the frame pairs. For each of the six scenes, generate two stills — the frame you want the shot to start on and the frame you want it to end on. Both built from the reference sheet, both using the identity prompt, both at the aspect ratio the final shot will render. The last frame of scene N should match the first frame of scene N+1 one-to-one; this is where the match line lives. These are image renders, not video renders, so they do not spend credits from the video shelf and they parallelise cleanly across however many threads the image side will serve.

Pass two, in-order per shot, parallel across shots: the videos. With all twelve stills in hand, the six video renders can all queue at the same time. Each one is self-contained: it has the reference sheet, the identity prompt, the first frame, the last frame, and the motion prompt. No scene waits on another to finish. The queue is wide, the result is a chain.

This is the shape the vendor-side batch posts miss. They queue the videos but have no mechanism for the frame-pair gate; they end up with six scenes of a person who looks like themselves on average and nobody on scene four. The gate is manual and it is the whole thing.

Which engine renders which scene

The six scenes are not six Kling shots. Some are character-close, some are motion-wide, some are a short cut-away. Mix the engines inside the batch:

scene	kind	engine	seconds	credits (720p voiced)
1 — opening on the character	voiced close	Kling O3 Pro	8	240
2 — reaction, tight	voiced close	Kling O3 Pro	6	180
3 — hero wide, motion-heavy	silent	Seedance 2.5	10	700
4 — the beat, two characters	silent	Seedance 2.5	8	560
5 — short cut-away	silent	Seedance 2.0 Fast	4	200
6 — closing on the character	voiced	Veo 3.1 Fast	8	240
			total	2,120

The whole six-scene story is 44 seconds of video for 2,120 credits. On the Creator plan (6,000 credits for $45) that is one of 2.8 episodes a month at $15.90 per episode. On Studio annual at 0.55c per credit, $11.66 per episode.

The two decisions that matter: scenes 3 and 4 go to Seedance 2.5 because 2.5 can render a 10-second shot in one generation and holds the reference set through long motion; scene 6 goes to Veo 3.1 Fast because the voiced close that lands on a specific expression is what Veo was designed for. Everything else is Kling.

Where the shot cap bites

Kling O3 Pro caps a single generation at 15 seconds. If scene 1 were 20 seconds of continuous character work rather than 8, that is two Kling renders joined with the same elements across both — the studio does the join through the segment pipeline, and the character holds because the elements are shared, but it does spend two renders.

Veo caps at 8 seconds flat. A reference-mode Veo render is pinned to 8 seconds whatever the slider says, so a 6-second voiced close rendered on Veo in reference mode bills for 8 seconds. Watch for this on the quote: the studio will tell you what you are paying before you render, which is the only place to catch the pin.

Seedance 2.5 and Seedance 2.0 do not cap below their maximums (30s and 15s respectively), so a long take on either goes in one render and the chain stays short.

The batch planner reads the shot cap off the catalogue and splits where it has to. The thing you want to avoid is a mental model where "I'll just render a 20-second Kling" — you cannot, and the batch will quietly join two renders for you.

The last-frame hand-off, in practice

The piece every vendor-side batch write-up glosses is how you actually hand the last frame of scene N forward. You can do it two ways, both of which the studio supports:

Save and re-upload. Render scene N, pull the MP4, extract the last frame, upload it as the first-frame still of scene N+1. Reliable, explicit, slow.

Pin inside the batch. The batch tool treats the pending render of scene N as a reference for scene N+1. The queue holds scene N+1 until scene N finishes, then pins the extracted frame automatically and submits. Faster, but it moves the batch from "wide parallel" to "serial chain" for the pinned pairs. We default to this for scenes that genuinely need the frame hand-off (the hero-wide → character-close transitions) and skip it for scenes separated by a cut (scene 5 → scene 6 is a hard cut, no hand-off needed).

The practical read is that about half the scenes in a six-scene story genuinely need the frame hand-off and the other half are hard cuts where the character hold rides entirely on the reference sheet. Half-serial, half-parallel is the honest batch shape.

What to do before the first batch

Open the studio with the free 300 credits and run two tests. First, a 4-second Kling O3 Pro voiced render of your character (120 credits) — this proves the reference sheet is tight. Second, a 4-second Seedance 2.5 silent render of the same character (280 credits — one of the credits goes over, fine, it costs 60c on Lite) — this proves the sheet travels across engines.

If both renders land on the same face, the reference chain is ready to carry a batch of six. If one of them drifts, tighten the identity prompt on the feature that moved and re-test before you spend the batch budget.

The honest limit on batch rendering a story is not the queue depth or the parallelism — it is the character work you did before you pressed the first submit. Every batch tool on the SERP will happily render six scenes of nobody; the character work is yours.