The cheapest and priciest Seedance host can be far apart

Updated 2026-10-02

Seedance is one of the most widely resold video models, and the same checkpoint is sold by many providers at very different per-second rates. The gap between the cheapest and priciest host in the live table is large enough to change a project budget. This page explains why the spread exists, then gives a way to decide between pinning a host and letting requests float, with reliability in the calculation.

Per second, before VideoRouter's 2% platform fee. For tiered models each row compares the resolution tier with the widest host-to-host gap. Built 2026-10-02 from the live catalog.

Why identical models are priced differently

VideoRouter does not publish any host's internal costs, so these are general reasons rather than per-host facts, and none of them is a quality signal:

• Different cost basis. Hosts can reach the model through different arrangements and regions.
• Different margin strategy. Some price a popular model aggressively to attract volume; others price for a premium product with extra tooling around it.
• Different tier menus. A host may offer resolution tiers or variants that others do not, so its price sits in a different place on the grid.
• Different service shape. Queue behaviour, rate limits and support differ even when the model is the same.

Because every host is reached through the same endpoint, you do not need a separate account to benefit from the cheap end. The question is how to use the spread without paying for it in failures.

What floating actually does

With no host specified, a request goes to the cheapest healthy host. If a submission is rejected it retries once on the same host, then walks the other hosts that serve the same checkpoint, cheapest first, until one accepts. That makes the cheap end your default and a more expensive host your fallback. Your realised average rate therefore sits between the cheapest row and whatever the fallback hosts charge, weighted by how often the cheap host is unavailable. When quoting a budget, treat the cheapest rate as the best case and the priciest as the worst case, and say which you used.

What pinning buys, and what it costs

Suffixing the model id (bytedance/seedance-2.5/fal) states a soft preference for one host, and the router can still fall back if that host rejects the job. A hard pin uses provider: {"only": ["fal"], "allow_fallbacks": false} and gives exactly one attempt, with an immediate error if it fails. Pinning is justified by:

• A capability only some hosts offer, such as reference video or audio arrays, or a specific resolution tier.
• A contractual or data-handling requirement for a named provider.
• Reproducibility: you want every shot of a sequence to come from one host.

The cost of a hard pin is that you pay that host's rate every time and lose automatic failover. If the pinned host is also at the expensive end of the table, you are paying the spread, as a deliberate choice.

Reliability-adjusted thinking

A cheap host is not cheap if jobs fail or sit in queue. Failed upstream jobs are not billed, so the direct money cost of a failure is zero, but the indirect cost is your time, your latency budget and your users' patience. Two signals can be requested explicitly instead of guessed:

• provider.sort accepts price (the default), latency (measured generation time), reliability (measured 24 hour success rate, highest first) and queue (measured wait before generation starts).
• Named policies lowest_cost, fast_finish, most_reliable and fast_start are shorthand for those sorts.
• provider.preferences hard-filters hosts by max_p95_latency_ms and min_success_rate.

A host with no measured data sorts to the back for that criterion, so a new or rarely used host will not win a reliability sort by default. VideoRouter's documentation notes that queue timing relies on each provider's own poll responses and is a softer signal than generation time and success rate. These controls reorder the same fallback walk, so you can prefer reliability for a customer-facing feature without abandoning failover.

A decision rule by workload

Measure before you commit

Do not rely on a quote from an article, including this one. Rates change and hosts come and go, which is why the table above is regenerated from live data. A sound routine: run a small, fixed prompt set on the floated default and on one pinned alternative at the same tier and duration, record cost, completion time and failures per job, then compute cost per kept clip. Dividing spend by usable clips folds reliability and your own keep rate into a single comparable number. The per-minute budget guide and the Seedance versus Kling comparison show how to extend that.

The pricing page has every Seedance row, the cost page turns rates into 5, 10 and 60 second clips, and the quickstart has a working request. Create a key to run the comparison yourself.

Frequently asked questions

Keep reading

• How to Reduce Your Seedance API Cost — Five Practical Levers
• Seedance API Cost Per Minute: Budget Formula & Retry Math
• Seedance vs Kling API Pricing: A Fair Cost Comparison
• Seedance 2.0 Mini vs Fast vs Full: A Cost Strategy for Teams