The Seedance 2.5 API Batch Workflow for 70 Episodes

What the Seedance 2.5 API Batch Workflow Looks Like for a 70-Episode Series

Episode nine is where the interface stops working. A generation operator running shots one at a time through a web interface can hold the state of a single episode in their head. Shot names, which reference set was used, which take was approved, which prompt variant produced the usable version. At around 400 shots that memory fails, and the failure is invisible until a continuity error surfaces twelve episodes later and nobody can reconstruct which parameters produced the shot that broke.

A 70 episode vertical drama series is roughly 3,000 to 4,000 generated shots depending on coverage density. That volume is not an interface problem. It is a data problem, and the only workable answer is to drive generation through the API with a job record for every shot, a queue that manages itself, and automated rejection that removes most failures before a human ever looks at them. What follows is the workflow shape, stage by stage.

1. The Job Object: What One Batch Row Actually Contains

Everything downstream depends on the job object being complete before any call is made. One row per shot, with a stable shot identifier, episode number, scene number, shot number within the scene, and a revision counter. The identifier never changes for the life of the production. Revisions increment. This is the single decision that determines whether the archive is usable in eighteen months.

Alongside the identifier sits the generation payload. Prompt text broken into its structural layers, reference asset identifiers rather than file paths, aspect ratio, duration, seed, and any camera or motion parameters the model exposes. Reported capabilities in the 2.5 release include longer single shot durations and a substantially larger reference input allowance, as covered in CineD's report on the Seedance 2.5 API going live, which changes how much of a scene can be planned as one job rather than assembled from fragments. The job object has to be able to carry that, which means reference identifiers need to be a list rather than a field.

Then the control fields. Status, attempt count, cost accrued, timestamps for submission and return, the operator who owns the shot, and the review outcome. These fields are what turn a spreadsheet of prompts into a production system. A job object without control fields produces output. A job object with them produces a production you can report on, which is the difference between a workflow and a pipeline.

2. Stage One: Shot List Normalisation Before Any Call Is Made

Nothing enters the queue until the shot list is normalised. Normalisation means every shot has been checked for the same set of conditions: a valid identifier, a resolved reference set, a duration inside the model limits, a prompt that passes the structural check, and an assigned operator. A shot that fails any of these does not get submitted and does not get a placeholder. It goes to a rejection list with a named reason.

The reason this stage exists is cost. Every malformed job that reaches the API burns credit and returns something unusable, and at 4,000 shots even a five percent malformation rate is 200 wasted generations. Catching malformation locally costs nothing. Building the normaliser is a day of work at the start of a production and it pays back inside the first episode.

Normalisation is also where episode level consistency gets enforced. All shots in a scene should reference the same locked asset set unless a deliberate change has been recorded. All shots in an episode should carry the same style definition. A normaliser that checks these conditions catches the class of error that is cheap to fix before generation and expensive to fix after, which is the entire economic argument for the stage.

3. Stage Two: Reference Locking and the Asset Registry

Character consistency across 70 episodes is not a prompting problem. It is a version control problem. Every character, location and recurring prop needs an entry in an asset registry with a stable identifier, a locked reference set, and a version number. The registry is the source of truth, and job objects reference it by identifier rather than embedding file paths that will move.

Locking means a reference set cannot be edited in place. If a character reference needs to change, a new version is created and the change is recorded with a date, a reason and the episode from which it applies. Shots generated before the change keep pointing at the old version. This is what makes it possible to answer the question that always arrives eventually, which is why the lead looks slightly different in episodes 34 to 38.

The larger reference input allowance in recent model versions makes this more valuable rather than less. More reference slots means richer character definition and better cross session stability, but it also means the reference set is now a substantial asset in its own right. Losing track of which combination of fifty inputs produced a stable character is a materially worse outcome than losing track of which of three inputs did. The registry is the mitigation.

4. Stage Three: Queue Design, Concurrency and Retry Policy

The queue is a worker pool pulling normalised jobs, submitting them, polling for completion and writing results back. Three parameters govern its behaviour. Concurrency, which is how many jobs are in flight at once. Retry policy, which is what happens on a failure. And priority, which is how the queue decides what to run when there is more work than capacity.

Concurrency should be set below the account rate limit with headroom rather than at it. Running at the ceiling produces throttling errors that look like generation failures in the logs, and diagnosing those wastes more time than the extra throughput was worth. A queue that runs at seventy percent of the limit and never throttles is faster in practice than one that runs at the limit and spends time recovering.

Retry policy needs to distinguish transient failure from deterministic failure. A timeout or a rate limit response retries with backoff. A malformed request or a content rejection does not retry, because it will fail identically every time. Retrying a deterministic failure three times is a straightforward way to triple a cost line without producing a single additional usable shot. Cap total attempts per job and route exhausted jobs to human triage rather than letting them cycle.

Priority ordering should follow the edit, not the episode number. Shots that unblock an editorial assembly go first. Establishing shots and hero moments that set the reference standard for a sequence go before the coverage around them. A queue that runs strictly in episode order will have editorial waiting on a single missing shot while three hundred later shots complete ahead of it.

5. Stage Four: Automated Rejection Before Human Review

Most generation failures are detectable without a person. Wrong duration, wrong aspect ratio, black or near black frames, a static frame where motion was requested, a frame count that does not match the request, a file that does not decode. Every one of these can be checked programmatically the moment the asset returns, and every one of these should be, because human review time is the scarcest resource on an AI native production.

The automated pass runs immediately on return and writes a verdict to the job object. Failures route straight back to the queue with the reason attached. Passes move to human review. On a well tuned pipeline this pass removes a meaningful share of returns before anyone opens a player, and the share is high enough that the checker pays for itself within the first two episodes of a series.

Content and consistency checks can be partially automated too, with care. Face embedding similarity against the locked character reference gives a numerical consistency score that catches drift reliably enough to be worth running, provided it is used as a flag rather than a verdict. Set a threshold that flags the bottom band for mandatory human review rather than auto rejecting, because the score is a proxy and proxies fail in ways that matter creatively.

6. Stage Five: Human Review, Sampling and Escalation

Human review at this volume has to be structured as sampling plus exception handling rather than as full coverage. Every shot flagged by the automated pass gets reviewed. Every hero shot, every shot with a face in close up, and every shot at a scene boundary gets reviewed. The remaining coverage gets sampled at a rate that is set at the start and adjusted based on what the sampling finds.

The sampling rate is the lever. Start high, at something like one in three, and reduce it as the pipeline demonstrates stability on that series. If the sample turns up a defect rate above the threshold, the rate goes back up and the underlying cause gets investigated rather than the individual shots getting patched. A rising defect rate in the sample is almost always a reference or prompt structure problem rather than a run of bad luck.

Escalation has to be defined before it is needed. A reviewer rejecting the same shot three times is not a reviewer problem, it is a specification problem, and the third rejection should escalate to whoever owns the scene rather than triggering a fourth attempt. Most of the cost overrun on AI native productions comes from unbounded retry loops on a small number of stubborn shots, and a hard escalation rule is what bounds them.

7. Stage Six: Cost Control as a Production Metric

Cost per approved shot is the number to watch, not cost per generation. A pipeline generating cheaply and approving one in six is more expensive than one generating at a higher unit cost and approving one in two. Tracking only spend gives no signal about which of those you are running, and by the time the difference shows in a budget review, thirty episodes are already produced.

Instrument the job object to carry accrued cost and attempt count, then report cost per approved shot weekly by episode and by scene type. Patterns surface fast. A particular location that consistently needs four attempts is a reference problem. A particular character that needs more attempts in dialogue coverage than in wides is a consistency problem at close range. Both are fixable, and both are invisible without the per shot accounting.

Set a per shot attempt budget and a per episode cost ceiling, and make breaching either one an event rather than a discovery. The ceiling does not have to stop work. It has to produce a decision, made by someone with the authority to change the specification, rather than a silent absorption that shows up at the end of the series.

8. Stage Seven: Versioning, Archive and Handover

Every approved shot is archived with its full job object attached. Prompt, references by identifier and version, seed, parameters, model version, attempt history and approval record. The model version matters more than teams expect, because a model updating mid production changes output characteristics, and the archive is the only way to know which episodes were produced under which version when that happens.

Archive structure follows the identifier scheme. Series, episode, scene, shot, version. Flat naming with a manifest is more durable than deep folder nesting, because folder structures get reorganised by whoever inherits them and manifests do not. The public record of the model line, including version history for Seedance and its releases, is worth capturing in the manifest alongside the internal version string, so that a future team can reconstruct the technical context without relying on institutional memory.

Handover is the test of whether the archive works. Give a generation operator who was not on the production a shot identifier and ask them to reproduce it. If they can, from the archive alone, the production is genuinely sequel ready and the asset layer has real value. If they cannot, what exists is a folder of finished video, which is worth considerably less to whoever commissions the second season.

Axis AI Studios Perspective

The batch workflow is not an efficiency exercise. It is what makes a 70 episode series governable, and governability is what a platform is actually buying when it commissions at volume. A production that cannot answer which parameters produced a given shot cannot correct a drift, cannot reproduce a look for a sequel, and cannot hand over cleanly if the team changes. Those are commercial properties, not technical ones.

Axis AI Studios builds every series against a job level record for this reason, and treats the asset registry and the archive as deliverables rather than as internal housekeeping. The position we hold is that the pipeline discipline is the product. Model capability moves constantly and every studio has access to broadly the same tools, so the durable difference is in whether a production can be reported on, corrected mid flight and rebuilt from its own records.

Axis AI Studios is an AI native vertical drama production studio based in the Netherlands, working with platforms, media companies and IP holders on original vertical series. If you are planning a series at this volume and want the pipeline architecture reviewed before production starts, write to business@axisaistudios.com.

FAQ

How many shots should a 70 episode vertical drama series be planned for?
Between 3,000 and 4,000 for most series, depending on coverage density and how much dialogue is carried in two shots rather than singles. Plan the shot list before pricing the generation, because the shot count is the cost driver and the episode count is not.

Can the batch workflow run without engineering support?
Partly. The queue, the automated rejection pass and the reporting need someone comfortable with scripting and an API, which is typically a technical director rather than a full engineering team. The asset registry and the shot list normaliser can be built on existing production tooling.

What happens when the model updates mid production?
The archive carries the model version per shot, so the affected range is identifiable immediately. The decision is then whether to finish the series on the pinned older version or to recalibrate references against the new one and accept a defined transition point. Both are workable. Discovering the change through inconsistent output is not.

Further Reading

For the release context behind the current model line, the Seedance 2.5 release breakdown covers what the July 31 version changed for vertical drama production specifically.

For the work that has to happen before any batch is queued, the guide to testing character consistency across sessions covers how to validate a reference set before a full series enters production.

For the prompt layer inside the job object, the five layer prompt structure for AI vertical drama generation covers what each layer does and why the order changes the output.