Skip to content

Seedance 2.0 image-to-video

Overview

Seedance 2.0 image-to-video is the simpler MuAPI-flavored entry point for turning one or more reference images into motion. In practical portal terms, these entries are best described as integration-layer products: the repo holds model-specific metadata and routing, but the pricing implementation is custom and lives in the application rather than coming from an authoritative provider usage object.

API base URL

https://api.muapi.ai/api/v1/

Example payload

{
  "prompt": "Animate the reference image into a cinematic reveal",
  "images_list": [
    "https://example.com/ref1.jpg"
  ],
  "aspect_ratio": "16:9",
  "duration": 5
}

Our Current Pricing

MuAPI video billing is custom application logic rather than provider-native metering. The activity computes price from duration, output resolution, fps, reference complexity, and whether a source video is present. seedance-2-image-to-video is not described with a separate pricing function in MODEL_COSTS_OVERVIEW.md, so the cleanest approach is to map it to the non-omni MuAPI formula with a lower input-complexity profile and to keep that mapping explicitly configurable.

Shared MuAPI base values:

base_price_per_second = 0.06 USD
resolution_multiplier = 1.5 for 1080p or 1920-wide outputs, otherwise 1.0
fps_multiplier        = 1.2 for 30 fps, otherwise 1.0

Preferred model branch from the current implementation:

seedance-2.0-omni           -> model multiplier 1.4
seedance-2.0-omni-reference -> model multiplier 1.6
unknown                     -> model multiplier 1.4

Combined formula:

raw_cost =
  ceil(duration_seconds) *
  base_price_per_second *
  resolution_multiplier *
  fps_multiplier *
  combined_multiplier

final_cost_usd = max(round(raw_cost, 2), 0.05)

The combined_multiplier is where most of the pricing nuance lives. It grows with input complexity, especially when many reference images or a source video are present. For the omni-reference branch, the code caps the combined multiplier at 3.0.

The right cost-calculation pattern is to compute the bill line from your stored request envelope and any normalization you apply before sending to MuAPI. If the provider response later starts returning explicit usage, keep your current formula as a fallback and reconciliation baseline, not the other way around.

Sources