How fresh are Sume's video prices? Rate-card dates per model

A video price table is only as good as the day someone last checked it. Sume's catalog records the date of the provider list price behind every per-second or per-token rate, and bills that list price times 1.25, rounded up to the cent per job. The price you see in GET /v1/videos/models is the billable rate; the date tells you how old the underlying list price is.

Below is the date attached to each model in the repo on 2026-10-07. Four of the seven rows carry a note that the price is subject to change, and the table repeats that note.

The date behind each rate

What the oldest dates mean

Seedance 2.5 and Grok Imagine Video 1.5 are priced from late-June rate cards, three months old on the day of reading. Those are the two rows to re-check against the live catalog before you commit a large batch. Sume has no way to promise that a provider has not moved its list price since; the catalog constraints for Wan 3.0, MiniMax H3 and Omni Flash say outright that the rate is subject to change.

The practical rule is to quote from the API, not from a blog table, including this one. GET /v1/videos/models returns pricing_skus per model, and the job's usage.cost is the Sume billable amount after the job completes.

Check the live rate in four lines

This prints every model and its SKUs, so you can diff against the numbers above.

curl -s https://api.sume.com/v1/videos/models \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | jq -r '.data[] | [.id, (.pricing_skus | tostring)] | @tsv'

Budget for drift

Add a margin to any plan that depends on one model for a whole quarter. A 10 percent cushion on a 1,000-clip run of Wan 3.0 at 720p, 5 seconds (63 cents per clip, $630 total) is $63. Sume reserves the billable amount when the job is submitted, so a balance that is short returns an error before generation starts instead of mid-batch.