HeyGen bills 2K at 3x its 768p rate: price a resolution bump on Sume

Before you add a "2K" switch to your app, find out what the switch costs. HeyGen's changelog (read 2026-10-07) says 2k bills at 3 times the 768p rate, for output seconds and reference-video seconds alike, on its POST /v3/models/videos endpoint. That multiplier is HeyGen's. On Sume there is no multiplier to memorize: each model's resolutions and price lines come from GET /v1/videos/models, and Sume reserves the estimated amount when it accepts the job.

So the rule is: read price per model and per resolution from the catalog at deploy time, show the estimate to the user, and let the balance check reject what the workspace cannot afford.

What each vendor's page says

Compare like for like. The HeyGen facts below are quoted from its changelog; the Sume facts are from the video generation guide.

Where the number comes from on Sume

Sume's docs say video billing reserves provider list price times 1.25 at submit, and that usage.cost on the job is the Sume billable amount. A completed job captures the reservation; a failed or canceled job releases it. You can see the three ledger states, reserved, captured and refunded, at GET /v1/usage.

One model-specific note from the docs: for minimax-h3, Sume bills 2K/4K upscales when your request includes them. If your product has a quality toggle, test the exact request, not the base resolution.

List what a toggle would cost

This prints each video model's resolutions and price lines so a product manager can see the choices before you build the toggle. It prints data; it does not invent a price.

import json, os, urllib.request


def main():
    req = urllib.request.Request(
        "https://api.sume.com/v1/videos/models",
        headers={"Authorization": "Bearer " + os.environ["SUME_API_KEY"]},
    )
    with urllib.request.urlopen(req, timeout=30) as resp:
        models = json.load(resp)["data"]
    for m in models:
        print(m["id"], m["supported_resolutions"], m.get("pricing_skus"))


main()

Decision rule

Gate any resolution above your default behind an estimate screen. Sume returns 402 insufficient_credits when the balance cannot cover the requested generation, so that failure is cheap, but a surprised user is not. Quote the catalog price, not a multiplier from another vendor.

Two traps when you add the toggle

The first trap is hard-coding a ratio. A ratio is true for one vendor on one day. If you copy HeyGen's 3x into your own estimate screen and then route the same user to a different model, your estimate is wrong in both directions.

The second trap is forgetting the duration axis. Sume video models list supported_durations as well as resolutions, and the longest clip you may request differs by model, so an estimate must multiply by the real requested seconds.

• Fetch the catalog on a schedule and cache it with a short expiry.
• Estimate from the exact request body, resolution and duration included.
• Show the user the estimate and the resolution you will send.
• After completion, store usage.cost from the poll response so your books match the ledger.