Seedance 2.5's API opens on August 7. ByteDance published the pricing ahead of it, and there is a detail in there that will quietly break your cost model if you carry it over from 2.0.
Video is quoted per second and metered per token:
tokens = (input_video_seconds + output_seconds) × width × height × fps / 1024
fps is fixed at 24. Multiply by the per-million-token rate and that is the bill.
USD per million tokens:
| Model | No video input | With video input |
|---|---|---|
| Seedance 2.5 (480p, 720p) | 10.70 | 6.40 |
| Seedance 2.0 (480p, 720p) | 7.00 | 4.30 |
| Seedance 2.0 (1080p) | 7.70 | 4.70 |
| Seedance 2.0 (4K) | 4.00 | 2.40 |
2.5 costs 52.9% more per token without video input and 48.8% more with it. Only 480p and 720p are published for 2.5. No 1080p, no 4K, and offline inference reads "not supported yet".
Look at the 4K row before you move on. It is the cheapest tier per token, 43% below 480p, and it is also the most expensive output on the board, because a 3840×2160 frame carries 19.4 times the pixels of what 480p actually renders. The rate drops 43% while the token count climbs 1940%. Comparing providers by scanning the rate column gets you the wrong answer by roughly a factor of eleven.
This is not in any release note. It falls out of dividing ByteDance's own worked examples by their own token rates.
Their published five-second, 16:9, no-reference examples:
| Model | 480p | 720p |
|---|---|---|
| Seedance 2.5 | $0.514 ($0.103/s) | $1.156 ($0.231/s) |
| Seedance 2.0 | $0.352 ($0.070/s) | $0.756 ($0.151/s) |
Divide price by token rate to recover the token count, then by 24/1024 to recover pixels:
const tokens = pricePerVideo / (ratePerMillion / 1e6);
const pixels = (tokens / outputSeconds) * (1024 / 24);
// Seedance 2.5, 480p: 0.514 / (10.70/1e6) / 5 = 9,607 tokens/sec
// 9,607 * 1024/24 = 409,899 px -> ~854 x 480
// Seedance 2.0, 480p: 0.352 / (7.00/1e6) / 5 = 10,057 tokens/sec
// 10,057 * 1024/24 = 429,105 px -> ~873 x 491
720p resolves to 21,600 tokens per second on both versions, which is exactly 1280 × 720. That the same arithmetic lands on a clean, verifiable number at 720p is what makes the 480p result trustworthy instead of a rounding artifact.
So 2.5 renders 480p at a true 16:9 854 × 480 while 2.0 uses a slightly taller frame. That 4.5% pixel reduction explains a discrepancy that otherwise looks like a pricing error: 480p rises 46% per second while the token rate rises 53%. At 720p, where the frame is unchanged, the two match exactly.
If you quote customers per second, your 2.0 conversion factor is wrong on 2.5 by about five percent at 480p.
input_video_seconds
sits inside the same parenthesis as the output. A reference-to-video job pays for the source clip at the same rate as the frames the model invented.
Providers surface this as a discounted per-second rate for reference mode, which reads like a deal until you total it. Seedance 2.5's published range makes the point on its own: a five-second 720p generation costs $1.244 with a short reference and $4.838 with a 30-second one. Same output, 3.9× the bill.
2.5 also doubled the input window, from 15 seconds on 2.0 to 30.
There is a floor too, and the number is unpublished. Their examples price two-second and four-second inputs identically, which implies a minimum around four seconds. The docs point at a spreadsheet calculator rather than stating it. If you resell this, customers sending two-second clips cost you more than your arithmetic predicts.
const TOKENS_PER_SEC = {
'480p@2.5': 854 * 480 * 24 / 1024, // 9,607
'480p@2.0': 864 * 496 * 24 / 1024, // 10,044
'720p': 1280 * 720 * 24 / 1024, // 21,600
'1080p': 1920 * 1080 * 24 / 1024, // 48,600
'4k': 3840 * 2160 * 24 / 1024, // 194,400
};
function costUsd({ tier, ratePerMillion, inputSec = 0, outputSec }) {
const tokens = (inputSec + outputSec) * TOKENS_PER_SEC[tier];
return (tokens * ratePerMillion) / 1e6;
}
// Sanity check against the vendor's own example:
costUsd({ tier: '720p', ratePerMillion: 7.0, outputSec: 5 }); // 0.756
That last line matches ByteDance's published figure exactly, so the formula is not an approximation.
One caveat for anyone metering downstream: token counts are estimates until the job finishes. The formula predicted 40,176 for a config where the API returned 40,594, about 1% high. Bill on the returned usage.completion_tokens
, not on your estimate.
Why 1080p and 4K have no published rate for 2.5. Either those tiers do not ship at launch or they arrive separately.
The exact minimum input duration. It exists and it is not a published number.
Whether the same formula holds outside the Seedance family. Pixels × duration × fps is a plausible general shape, but the constants and the input-billing rule are not something I would assume for Veo, Kling or Sora without checking. If you have run the same back-solve against those, I would genuinely like to know how it came out.
Full writeup with the Seedance 2.0 rate card in per-second and per-minute terms: reapi.ai/blog/seedance-2-5-pricing-per-token
Live parameter reference and a browser playground: reapi.ai/models/seedance-2-0