Skip to content

Seedance 2.0 first-last-frame

Overview

Seedance 2.0 first-last-frame is the constrained variant that focuses on interpolation between explicit boundary frames. 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": "Generate a smooth transition between the first and last frame",
  "images_list": [
    "https://example.com/first.jpg",
    "https://example.com/last.jpg"
  ],
  "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-first-last-frame is likewise not called out separately in the pricing overview, so it should be documented as a request-shape variant that inherits your configured MuAPI rate card unless you introduce a dedicated branch.

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