Chapter 9 of 9. Prerequisite: Chapter 3. You can submit role-tagged requests and run beats in parallel. This chapter is the reference card: every hard limit the API enforces, dated, plus what a film actually costs when you render one instead of reading about one.
Eight chapters of this course discovered constraints the expensive way, one 400 at a time. This chapter collects them in one place, stamps a date on them, and puts the money next to them. Constraint knowledge in this ecosystem lives scattered across error responses; cost knowledge lives on the invoice. Both belong on one page you can check before a batch, because the difference between a disciplined film and an accidental one is about a factor of five in spend.
Seedance 2.0 limits: duration, resolution, ratio, the dated catalogue
The full table of hard limits, as verified on this account on 2026-07-23. The parameter names are the create-task API's; the reference-media modalities are the ones the Seedance 2.0 series tutorial documents; the rate limits follow the burst-traffic contract.
| Constraint | Value (2026-07-23) |
|---|---|
| Duration, Seedance 2.0 | 4 to 15 seconds per render, or -1 for auto |
| Duration, Seedance 1.x | 2 to 12 seconds per render |
| Resolutions | 480p, 720p, 1080p, 4k (4K on 2.0 only, 10-bit H.265) |
| Ratios | 16:9, 4:3, 1:1, 3:4, 9:16, 21:9, adaptive |
| Input budget, 2.0 | text + 0-9 images + 0-3 videos + 0-3 audios; no audio-only or text-plus-audio-only |
| Reference video pixel floor | at least 409,600 pixels per frame (854x480 for 16:9) |
| Reference video transport | public web URL only; base64 data URIs rejected |
| Rate limit, non-4K | 180 requests per minute, 3 concurrent tasks (individual accounts) |
| Rate limit, 4K | 15 requests per minute, 1 concurrent task |
| Watermark | defaults on, burns an AI-generated tag; send "watermark": false for clean output |
service_tier: "flex" | offline processing at half cost; not available on 2.0 |
Two of these rows do more damage than the rest combined.
The 4-second floor is a creative constraint, not a billing one. Seedance 2.0 will never render shorter than 4 seconds. Render --duration 5 against a 2.5-second motion-reference beat and the model follows the choreography for 2.5 seconds, then improvises the tail with invented poses and invented props. This pipeline learned it as mid-move cuts across a whole batch. The fix is Chapter 7's rule, match the render duration to the usable length of the reference, and where the beat is shorter than 4 seconds, accept the floor and trim the tail in the edit.
The 15-second ceiling shapes the whole film grammar. One render is one continuous take of at most 15 seconds: duration is a documented parameter on the create-task API, and the 4-to-15 window on the 2.0 series is as verified on this account, 2026-07-23. Longer scenes are independent shots cut together, with identity held by registered assets (Chapter 4) and the environment held by scene plates (Chapter 6). The official launch post describes the four input modalities that make that shot-based grammar workable; nothing in the API gives you a persistent world beyond them.
The rejection catalogue: five hard 400s and the billing block
Five hard 400s gate this pipeline, and one billing block sits in front of all of them. Each string below is quoted from a real rejection, so you can grep for it when it lands.
1. Frame continuity and reference media are mutually exclusive.
first/last frame content cannot be mixed with reference media content
Seedance treats first/last-frame image-to-video and reference_image/reference_video as separate modes on the create-task API. You cannot chain shots by feeding the previous render's last frame while also carrying character assets and a motion reference. This single constraint forced the course's pivot from frame-chaining to independent hard-cut shots.
2. Camera lock is rejected whenever reference media is present.
HTTP 400 "camera_fixed is not supported for dreamina-seedance-2-0 in r2v, must be empty"
Any reference input, including an asset:// character id, puts the request in reference-to-video mode, and camera_fixed must then be absent. Camera consistency is a prompt and post-production job in this pipeline, always.
3. The reference-video pixel floor.
video pixel count must be >= 409600
A 640x360 clip (230,400 pixels) is rejected; the same clip re-encoded at 960x540 (518,400 pixels) passes. Encode 16:9 reference cuts at 854x480 or better before hosting them.
4. Reference video must be a web URL.
InvalidParameter: reference_video must be provided as a web url
Images accept base64 data URIs; videos do not. This is why the hosting workflow exists at all: a local static server behind an unguessable public HTTPS URL from a quick tunnel, torn down after the batch.
5. Roles are mandatory on 2.0 reference items.
role must be specified for image contents
An HTTP 400 from the first Seedance 2.0 call this pipeline ever made. Every reference item on the 2.0 series carries a mandatory role: reference_image for images, reference_video for videos, reference_audio for audio, with frame anchors using first_frame and last_frame instead. Chapter 3 covers the role structures and how the CLI assigns them.
And the billing block that fires before any of these can.
SetLimitExceeded
The error code returned when a model has no quota to draw on. On this account it fired on the first Seedance 2.0 call before a resource pack was purchased, and the failed task incurred no charge. The related activation-time message is "No available resource packs. Please purchase a resource pack first.", which is the console's way of telling you the 2.0 series carries zero free quota.
Past the catalogue, the burst-traffic best-practices page documents the 429 you get for exceeding requests per minute, token usage or concurrency, with retry guidance. In practice the async task queue absorbs most of it: submit more than 3 concurrent non-4K tasks and the extras sit in queued on the retrieve endpoint rather than failing.
Moderation limits: what the filters block and what passes raw
Three moderation constraints, all input-side, all discovered live.
Real faces in raw uploads are blocked. HTTP 400 InputImageSensitiveContentDetected.PrivacyInformation on a face PNG, even an AI-generated one. The registered asset:// id for the same face passes. Chapter 4 covers the registration flow.
Real-person reference video is blocked until de-photographed. The edgedetect line-art treatment from Chapter 5 (ffmpeg -vf "scale=480:-2,edgedetect=low=0.1:high=0.3") clears the real-face detector while preserving silhouette and screen position. Anime and CGI reference footage passes raw with no treatment.
Sensitive poses are blocked independently of faces. InputVideoSensitiveContentDetected fired on a grapple pose inside an already-abstracted clip; the same line-art treatment on that segment cleared it. Weapon and graphic-violence content can also trip filters, so test a risky beat small and cheap before committing a batch to it.
The cost ladder: token rates, rate cards, free quota
Everything on ModelArk bills in tokens, with formulas and unit prices on the official pricing page. The numbers that matter for this pipeline, as of 2026-07-23:
- Seedance 2.0 at 480p bills 4.3 USD per million tokens when the request carries a video input, and 7 USD per million when it does not. An image-reference-only render pays the higher rate.
- Seedance 1.0 Pro bills 0.0025 USD per thousand tokens. The docs' reference point is roughly 247K tokens for a 5-second 1080p clip; measured on this account, a 5-second 720p clip lands near 110K tokens, which works out to about $0.28 per clip once free quota is exhausted.
service_tier: "flex"halves the cost for offline processing on the create-task API, and is not available on the 2.0 series.- Free quota: Seedance 1.0 Pro and Seedance 1.5 Pro each carried 2,000,000 free tokens on activation, as recorded on this account, 2026-07-23. On 1.0 Pro that is roughly 40 clips at 480p, 18 at 720p or 8 at 1080p. The Seedance 2.0 series carries zero free quota and requires a paid resource pack before it will activate. Quota figures live in the console, not on the public model pages, so check your own before budgeting against these.
The measured Seedance 2.0 rate card, for a 5-second shot with an image reference present:
| Resolution | 5s clip cost |
|---|---|
| 480p | $0.35 |
| 720p | $0.77 |
| 1080p | $1.73 |
| 4K | $6.65 |
Read that column vertically before every batch. A 720p shot costs 2.2x its 480p twin. A 1080p shot costs 5x. A 4K shot costs 19x, and 4K also drops you to 1 concurrent task, which kills the parallel pattern below. Per-model capability and limit cards, like the seedance-1.0-lite card, carry the per-model rate limits next to these prices.
Budget discipline: iterate at 480p, render in parallel
The whole economic argument of this course compresses to two rules.
Rule 1: 480p is the iteration resolution. Nearly every proof in this course happened at 480p: the face-lock validation ($0.35), the two-character mapping test ($0.40), the scene-plate lock. The one early exception, the first motion-transfer proof, ran at 720x1280 and cost about three times as much, which is its own argument for the rule. At $0.35 a shot you can afford to be wrong, and Chapters 4 through 8 were wrong often. Spend 720p money only on shots the edit has already decided to keep, and treat 1080p as a finishing decision for a locked cut, never an iteration setting.
Rule 2: the batch renders in parallel, always. The API is asynchronous by design: POST /contents/generations/tasks returns a task id immediately, and the poll endpoint reports queued, running, succeeded, failed or expired per task, plus cancelled for a task you cancel out of the queue. Nothing about a film's beats is sequential at render time, so submitting them one at a time buys you nothing except waiting. The pattern, exactly as this course runs it:
- Cut the source into beats, each its own file at or above the 409,600-pixel floor.
- Host all beat files behind one static server and one quick-tunnel HTTPS URL. One tunnel serves the whole batch, and it must stay up until the last poll completes, because the platform fetches reference videos during processing, not at submit time.
- Submit every beat before polling anything.
- Poll all task ids, download all MP4s, assemble in the edit.
# 1. submit the whole batch first
: > tasks.txt
for i in $(seq 1 8); do
curl -sS "$BASE/contents/generations/tasks" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $ARK_API_KEY" \
-d @"beats/b${i}.json" | jq -r '.id' >> tasks.txt
done
# 2. then poll everything until every task reaches a terminal state
while grep -qvE 'succeeded|failed|expired|cancelled' status.txt 2>/dev/null || [ ! -f status.txt ]; do
: > status.txt
while read -r id; do
curl -sS "$BASE/contents/generations/tasks/${id}" \
-H "Authorization: Bearer $ARK_API_KEY" | jq -r '.status' >> status.txt
done < tasks.txt
sleep 10
done
Each beats/b<i>.json is the beat's full request body: its directed prompt, the character assets, the scene plate and the beat's hosted reference URL. The 3-concurrent limit on non-4K tasks does not break this; beats 4 through 8 simply sit queued until a slot frees, and the loop drains the whole batch unattended.
The receipts for the pattern: 5 beats rendered simultaneously for a 35-second first film at ~$2.50 total; an 11-beat batch at ~$5.50 where one beat failed twice and was skipped rather than retried a third time; and the cleanest run in the arc, 8 directed-prompt beats submitted over one tunnel, all 8 succeeded first try, ~$3 to $4 total. Beyond the wall-clock saving, parallelism made whole-film re-renders cheap enough to treat as iterations.
What a film costs: the full ledger
Every dollar in this course's practice-film arc, from the ledgered record, so you can budget your own film against a real one rather than a rate card.
| Render | Spend |
|---|---|
| Character asset validation (480p, 9:16) | ~$0.35 |
| First motion-transfer proof (720x1280, 5s) | ~$1.00 |
| Two-character fight-mapping test (480p) | ~$0.40 |
| Continuous 12s two-character fight (480p) | ~$1.30 |
| First full movie, 5 beats in parallel (35s) | ~$2.50 |
| 11-beat parallel batch (one beat failed twice, skipped) | ~$5.50 |
| Single-beat windup re-render | ~$0.50 |
| Complete faithful 11-shot fight pass | ~$5.00 |
| Custom-prompt KO ending | ~$1.00 |
| 8-beat directed re-render, all first try | ~$3 to $4 |
Three readings of that table. First, the line items sum to roughly $21 for an entire short film's R&D, every failed experiment included, about the price of three 5-second 4K clips. The devlog's own session roll-up, about $16, covers the fight R&D through the complete faithful pass, retries included; the KO ending and the directed re-render landed after that roll-up. Second, the expensive line items are the batches, so the discipline that matters is per-batch: estimate before you submit. A useful planning number from the arc is 12 to 18 shots at roughly $6 to $9 for a 480p coverage pass. Third, validation renders are the cheapest line items on the sheet and they prevented the most expensive class of failure, a bad batch; the $0.35 face-lock check guarded every dollar below it.
Rights: what the output is, and is not
The binding posture this course ships under: outputs derived from third-party footage stay personal and non-commercial. The line-art abstraction that clears moderation does not erase the source's rights, and this course teaches prompts and rules, never a claim over footage derived from someone else's choreography. Films built entirely from material you own are a different matter, and everything in the nine chapters applies to them unchanged.
That is the course: four endpoints and nine chapters, on a rate card where being wrong costs $0.35. Go render something.
Add a pre-flight cost estimator to your submission loop
Extend your Chapter 3 batch harness so no batch is submitted blind. Before the first request fires, the harness must price the whole batch from the rate card, refuse to run past a configurable ceiling, and write an actual-vs-estimated ledger row per task as results come back.
Expected behaviour
- A printed pre-submission estimate covering every beat, computed from resolution, duration and the image-ref versus video-input rate difference
- A hard stop when the estimated batch total exceeds a ceiling you set in one place, with an explicit override flag required to proceed
- All beats submitted before the first poll, with beats beyond the concurrency limit observed sitting in queued rather than erroring
- A ledger file gaining one row per task: task id, model, resolution, duration, estimated cost and final status
- 480p as the harness default resolution, with 720p requiring an explicit flag
PROVE IT Run a three-beat batch at 480p. Show the printed estimate before submission, the queued statuses mid-run, and the finished ledger with estimated cost per task against the batch you actually observed.
You submit a Seedance 2.0 render with duration 5 against a motion-reference beat that is 2.5 seconds long. What happens?
What is the minimum per-frame pixel count a reference video must meet before the API will accept it?
Your film needs 12 shots. Walk through the budget discipline this chapter prescribes, from first render to finished film, with the numbers that justify each step.
Show answer
Iterate everything at 480p, where a 5-second shot with an image reference costs about $0.35, so a full 12-to-18-shot coverage pass lands around $6 to $9. Submit the whole batch in parallel over one hosted tunnel, because the async API returns task ids instantly and the 3-concurrent limit only queues the extras rather than failing them. Verify cheap with contact sheets and validation renders before any batch. Only re-render the shots the edit keeps at 720p, which costs 2.2 times the 480p rate, and treat 1080p and 4K as finishing decisions. The devlog's fight R&D roll-up through the complete faithful pass came to about $16, and the full arc's line items sum to roughly $21.
↺ re-read: “Budget discipline: iterate at 480p, render in parallel”