Seedance usage.cost on Sume: the billable amount, not provider cost

usage.cost in a completed Seedance poll response is the amount Sume bills you in USD. The docs define it as "the Sume billable amount", and the same docs say the workspace balance is reserved on submit at the provider list price times 1.25 for every model.

That makes usage.cost the number to put in your own bookkeeping, since it is what leaves your balance.

What does the poll response look like?

The docs show a completed job with usage: {"cost": 0.25, "is_byok": false}. That 0.25 is an illustration from the docs, not a price for any model.

Two practical consequences follow. Do not subtract it from the provider list price and call the difference a fee, because the docs describe the 1.25 factor as the pricing rule across every model, not a separate line. And do not compare it to a quote from another site without checking whether that site shows list price, credits or a membership rate.

How is it related to the reserve?

Money moves in stages. On submit, Sume reserves the list price times 1.25. When the job reaches a terminal state, the ledger records a capture or a refund. The /v1/usage endpoint lists those entries: reservations, captures, refunds and top-ups.

The reserve means your balance can be lower than you expect while jobs are in flight. If you submit twenty clips at once, twenty reservations are held until each job finishes, so a workspace with a small balance may refuse the later submits. A failed job refunds its reserve, as the ledger entries show.

For budgeting, a simple pattern is to sum usage.cost across completed jobs in your own database and compare it weekly with /v1/usage. Differences usually come from jobs still in progress or from a refund that has not yet been counted.

Can I estimate before submitting?

Yes, approximately. The model list returns pricing_skus, for example per-1000-video-tokens on the Seedance 2.0 sample entry. Multiply by 1.25 to get what Sume bills. How many tokens a clip uses depends on resolution and length; the fal token formula post works one example.

Be careful with estimates. A per-token price needs a token count, and the count depends on the clip. Run one real job at the settings you plan to use, read its usage.cost, and use that figure to project a batch. It is more reliable than arithmetic from a rate card.

What about workspace fal keys?

In the development preview, the docs say workspace admins can connect a fal key; then usage.is_byok is true and usage.cost is only the Sume fee, 5.5% of fal list price. The docs add that production remains disabled by default, so treat that as not generally available.