Pricing

Every model page on sunra.ai shows the price of each endpoint next to the model name — for example $0.045-$0.09 per image. Hovering the price shows a tooltip with the exact rule, such as which resolutions or options change the price. For most models the price of a request is fixed at submission time: it is computed from your request parameters before the model runs, and that exact amount is what appears in your billing history. The same request parameters always cost the same amount, so you can budget deterministically. A few models (for example video models billed per output second) settle after completion based on actual usage; their tooltips say so.

Pricing API

You can read prices programmatically — both as human-readable strings and as machine-readable rules.

Endpoint	Auth	Description
api.sunra.ai/v1/pricing	API key	Lists all models with `display` and `tooltip` price strings
api.sunra.ai/v1/models	none	Lists all models; gives you the model `id`
api.sunra.ai/v1/pricing/model/{model_id}/endpoint/{endpoint}	none	Full machine-readable price rules for one endpoint

Paging the pricing list

GET /v1/pricing returns a list envelope — { "object": "list", "data": [...], "has_more": … } — and takes:

Parameter	Meaning
`limit`	Rows per page, 1–10000. Defaults to 10
`starting_after`	The `id` of the last row you received; returns the rows after it
`model_ids`	Comma-separated model ids to restrict the list to

Page forward until has_more is false:

curl -s -H "Authorization: Key $SUNRA_KEY" \
  "https://api.sunra.ai/v1/pricing?limit=100&starting_after=mep_b1Mzl6kT3znJ"

A starting_after that is not the id of a row this endpoint returns is a 400 — it is never treated as “start from the beginning”. ending_before is not supported; page forward instead. If you just want the whole catalog in one call, a large limit works too. To compute the exact price of a request before sending it, first look up the model id:

curl -s "https://api.sunra.ai/v1/models?limit=300" \
  | jq '.data[] | select(.alias == "bytedance/seedream-5.0-pro") | .id'
# "model_b63ac71d3992"

Then fetch the price rules for the endpoint you plan to call:

curl -s "https://api.sunra.ai/v1/pricing/model/model_b63ac71d3992/endpoint/image-editing"

{
  "id": "mep_e5e2c1437feb",
  "object": "model_endpoint_price",
  "model_name": "seedream-5.0-pro",
  "model_endpoint": "image-editing",
  "display": "$0.045-$0.126 per image",
  "tooltip": "1K: $0.045, 2K: $0.09 per image, +$0.004 per reference image from the 2nd",
  "type": "pre_defined",
  "prices": [
    { "unit_amount": "0.045", "matches": { "resolution": "1K", "images": { "$size_lte": 1 } } },
    { "unit_amount": "0.049", "matches": { "resolution": "1K", "images": { "$size": 2 } } },
    { "unit_amount": "0.09",  "matches": { "images": { "$size_lte": 1 } } },
    { "unit_amount": "0.094", "matches": { "images": { "$size": 2 } } },
    { "unit_amount": "0.126" }
  ]
}

How price rules are evaluated

The prices array is evaluated top to bottom against your request payload, and the first row whose matches conditions all hold determines the price. A row without matches always matches — it is the fallback. Conditions compare your request parameters:

Condition	Meaning
`"resolution": "1K"`	Parameter equals the value exactly
`"duration": { "$gte": 5, "$lte": 10 }`	Numeric parameter is in range (`$gt`, `$gte`, `$lt`, `$lte`, `$in`, `$nin`)
`"images": { "$size": 3 }`	Array parameter has exactly 3 items (`$size_gt`, `$size_gte`, `$size_lt`, `$size_lte` for ranges)

A parameter that is absent from your request never matches a condition — defaults are not filled in before matching. Price tables are ordered so that omitting an optional parameter lands on the row for its default behavior. Worked example, using the table above:

{"images": [a], "resolution": "1K"} → first row → $0.045
{"images": [a, b, c], "resolution": "1K"} → 1K row with $size: 3 → $0.053
{"images": [a]} (resolution omitted, model defaults to 2K) → skips the 1K rows, hits $size_lte: 1 → $0.09

If a matched row has a usage_key, the amount is unit_amount × that parameter’s value (for example price per second of requested duration).

Seedance video token pricing

The Seedance 2.0 family (including the fast, mini and relay variants) and Seedance 2.5 are billed per token, not per output second. Their price rule is "type": "post_calculated": the amount is settled after generation from the usage the model reports. total_tokens in the prediction output is the authoritative quantity, and the charge is total_tokens × rate, with the rate quoted per 1M tokens. The rate depends on the output resolution and on whether the request carries reference videos — requests with input video are billed at a lower rate for the whole request. The rates per model are in the price tooltip on the model page and in the tooltip field of GET /v1/pricing/model/{model_id}/endpoint/reference-to-video. For these endpoints the machine-readable prices array carries only the settlement unit, because the token count does not exist until the model has finished generating.

How tokens are counted

tokens = floor(frames × width × height / 1024)

frames = 24 × output_seconds + 1                              # no reference video
frames = 24 × output_seconds + 1 + 24 × billed_input_seconds  # with reference videos

width × height is the resolution of the video you actually receive. With ratio: adaptive that follows your input, so it is not necessarily the aspect ratio you would assume from the resolution setting — read it from the output file if you want to reproduce a charge exactly. The frame count is accurate to about one frame (the upstream occasionally returns one fewer); total_tokens is always what you are billed on. Reference images and reference audio add no tokens. Only reference videos do.

Billed input seconds

Reference video is not billed for its literal length. The billed input duration is computed per task:

billed_input_seconds = max(floor(total actual input seconds), ceil(output_seconds × 2/3))

A short reference video with a long output still pays a floor of two thirds of the output duration — a 6 s clip on a 30 s output is billed as 20 s of input. Input seconds are summed across all reference videos and floored to whole seconds; the frame rate, resolution and encoding of the source video do not matter. Rare exception. For a small share of reference videos the upstream model counts more input than the clip contains — we have seen 17 s clips billed as 30 s (720 input frames) on Seedance 2.5, with the same clip re-encoded at 24 or 30 fps, at other resolutions or without audio billed the same way, and the same footage cut down to its first 8 s billed normally. The trigger is the video content itself, not any request parameter, so it cannot be predicted before generation. total_tokens in the prediction output is always what you are billed on.

Worked examples

Seedance 2.5, 720p 16:9 output — 1280 × 720 = 900 tokens per frame — with a reference video, at $6.40 per 1M tokens:

Output	Reference video	Billed input	Frames	Tokens	Amount
10 s	6 s	7 s (minimum)	241 + 168 = 409	368,100	$2.36
30 s	6 s	20 s (minimum)	721 + 480 = 1,201	1,080,900	$6.92
5 s	15 s	15 s (actual)	121 + 360 = 481	432,900	$2.77
30 s	24 s	24 s (actual)	721 + 576 = 1,297	1,167,300	$7.47

Draft mode (Seedance 2.5)

Seedance 2.5 can render a cheap 480p draft first and later upscale exactly that draft — same seed, same prompt and references — to 1080p without re-describing it:

Call text-to-video, image-to-video or reference-to-video with "draft": true and "resolution": "480p" (draft mode accepts no other resolution). The output carries a draft_task_id, valid for 7 days.
Call bytedance/seedance-2.5/draft-to-video with that draft_task_id (plus an optional output_format). The result is always 1080p; duration, ratio, audio and references are reused from the draft and cannot be changed.

Both steps are billed exactly like an ordinary request at their resolution: the draft at the 480p rate, the final at the 1080p rate. The final re-counts the draft’s reference-video seconds, so a draft made with reference videos settles its final at the with input video 1080p rate ($7.00 per 1M tokens on Seedance 2.5) and one made without at the without input video rate ($11.70). As always, total_tokens in each output is the billed quantity. Two things to know: draft mode is served only by the default (BytePlus) channel — a request that pins another provider with draft: true fails before generation — and the draft_task_id works like a signed URL: anyone holding it can finalize it at 1080p on their own account, so treat it as private.

MiniMax H3 family per-second pricing

The four official MiniMax H3 models are billed per second of output video, at a rate that depends on the output resolution you ask for:

Model	480P	768P	2K	Duration	Default resolution	Reference-to-video
`minimax/minimax-h3`	$0.038/s	$0.08/s	$0.13/s	4–15 s	2K	yes
`minimax/minimax-h3-max`	$0.05/s	$0.08/s	—	5–15 s	768P	yes
`minimax/minimax-h3-fast`	$0.046/s	—	—	4–15 s	480P	yes
`minimax/minimax-h3-max-turbo`	$0.025/s	$0.04/s	—	5–15 s	768P	no

For text-to-video and image-to-video the amount is fixed at submission ("type": "pre_defined"): it is the rate of the selected tier multiplied by the duration you request, in whole seconds. A 5 s 768P clip on minimax/minimax-h3 costs 5 × $0.08 = $0.40; the same clip at 2K costs $0.65. The resolution parameter picks the tier. Omitting it uses the model’s default resolution shown above — the price table is ordered so that a request without resolution lands on the default tier’s rows (see How price rules are evaluated). minimax/minimax-h3-fast serves 480P only and has no resolution parameter. minimax/minimax-h3-max-turbo has no reference-to-video endpoint; calling it returns 404 MODEL_ENDPOINT_NOT_FOUND.

Reference-to-video input materials

reference-to-video is settled after completion ("type": "post_calculated") from the usage MiniMax reports, because reference material is billed on top of the output:

amount = output_seconds       × output tier rate
       + reference_video_secs × reference video rate
       + max(0, reference_images − free images) × per-image price

Reference audio is free on every model. The reference rules differ per model:

Model	Free reference images	Each further image	Reference video per second
`minimax/minimax-h3`	5	$0.04	same as the output tier — 480P $0.038 · 768P $0.08 · 2K $0.13
`minimax/minimax-h3-fast`	5	$0.04	$0.046
`minimax/minimax-h3-max`	2	$0.074	480P $0.0553 · 768P $0.143

Note that minimax/minimax-h3-max bills reference video at its own rate table, which is higher than its output rate — reference video is the dominant cost in a reference-to-video request on that model.

H3 worked example

minimax/minimax-h3-max reference-to-video at 768P, 5 s of output, one 5 s reference video and 3 reference images:

Component	Quantity	Rate	Amount
Output	5 s	$0.08/s	$0.40
Reference video	5 s	$0.143/s	$0.715
Reference images	3 − 2 free = 1	$0.074	$0.074
		Total	$1.189

Topaz Hyperion 2.5 SDR-to-HDR pricing

topazlabs/hyperion-2.5/sdr-to-hdr is billed per frame, in credits of $0.10, and settled after completion ("type": "post_calculated"). Hyperion keeps the resolution, frame rate and duration of your input, so the charge is fully predictable from the input file:

frames_per_credit = 13.02   if width × height ≤ 1920 × 1080
                  = 5.9     otherwise (above 1080p, up to 4K)

credits = ceil( ceil(seconds) × fps / frames_per_credit )
amount  = credits × $0.10

seconds is the container duration rounded up to a whole second, and fps is the stream’s frame rate. For variable-frame-rate files the higher of the average and nominal rate is used, so re-encode to a constant frame rate if you want the lowest bill.

Input limits

A request is checked before it is submitted upstream and rejected with input_validation_failed — not billed — if the video exceeds any of these:

Limit	Value
Resolution	≤ 3840 px on either axis and ≤ 3840 × 2160 pixels
Frame rate	≤ 60 fps
Duration	≤ 5 minutes
Size	width × height × seconds ≤ 130,000,000
Estimated cost	≤ $30 per request

Only http(s):// video URLs are accepted; data: URIs are not.

Hyperion worked examples

Input	Rounded seconds × fps	Frames per credit	Credits	Amount
1280 × 720, 24 fps, 10.04 s	11 × 24 = 264	13.02	21	$2.10
1280 × 720, 24 fps, 15.04 s	16 × 24 = 384	13.02	30	$3.00
1920 × 1080, 30 fps, 60 s	60 × 30 = 1,800	13.02	139	$13.90
3840 × 2160, 24 fps, 15 s	15 × 24 = 360	5.9	62	$6.20

Topaz video-upscaler pricing

topazlabs/video-upscaler/video-upscale is billed per second of output video and settled after completion ("type": "post_calculated"). The per-second rate is set by the size of the output frame, so upscale_factor is what moves the bill:

rate = $0.01/s   if output_width × output_height ≤ 1280 × 720
     = $0.02/s   if output_width × output_height ≤ 1920 × 1080
     = $0.08/s   otherwise

amount = ceil(output_seconds) × rate
       × 2       if enhance_model is a Starlight variant
       × 0.5     if enhance_model is "Gaia 2"

Three details are worth reading twice:

The tier is the pixel count, not the height. A 1632 × 672 output is 1.10 megapixels, so it bills at the 1080p rate even though it is only 672 px tall; an 820 × 852 output is 0.70 megapixels and bills at the 720p rate even though it is 852 px tall.
Seconds round up. A 5.038-second output is 6 billable seconds.
Frame interpolation is free. Setting target_fps does not change the price, at any value.

Enhance model	Multiplier
`Starlight Precise 1/2/2.5`, `Starlight HQ`, `Starlight Mini`, `Starlight Sharp`, `Starlight Fast 1/2`	× 2
`Gaia 2`	× 0.5
`Proteus`, `Artemis HQ/MQ/LQ`, `Nyx`, `Nyx Fast`, `Nyx XL`, `Nyx HF`, `Gaia HQ`, `Gaia CG`	× 1

Video upscaler worked examples

Output	Enhance model	Billed seconds	Rate	Amount
1280 × 720, 10 s	`Proteus`	10	$0.01/s	$0.10
1632 × 672, 5.038 s	`Starlight HQ`	6	$0.02/s × 2	$0.24
3840 × 2160, 30 s	`Gaia 2`	30	$0.08/s × 0.5	$1.20

Qwen Image Layered pricing

qwen/qwen-image-layered/image-to-image returns one image per layer and is billed **

0.05 per output layer**, so the price is `

0.05 × num_layers. num_layers

 accepts 1–10 and defaults to 4, which makes the default request $0.20. Because the count is an input, the price is known before the job runs (

”type”: “pre_defined”`).

FLUX.2 [pro] image-to-image pricing

black-forest-labs/flux-2-pro/image-to-image is billed per processed megapixel and settled after completion ("type": "post_calculated"). One megapixel is 1024 × 1024 = 1,048,576 pixels.

megapixels = (number of reference images)      # 1 MP each, whatever their size
           + ceil(output_width × output_height / 1,048,576)

amount = $0.03 + $0.015 × (megapixels − 1)

Two things are worth knowing before you upload:

A reference image always costs exactly 1 megapixel, however large it is — the model downsamples it, and there is no discount for sending a small one either.
Each image is rounded up on its own, so a 1536 × 1024 result (1.5 MP) counts as 2 MP.

image_urls accepts up to 8 reference images. text-to-image is unaffected: all of its aspect ratios fit in one megapixel, so it stays a flat $0.03 per image.

FLUX.2 [pro] worked examples

Reference images	Result	Megapixels	Amount
1 × any size	1024 × 1024	1 + 1 = 2	$0.045
2 × any size	1024 × 1024	2 + 1 = 3	$0.06
2 × any size	1536 × 1024	2 + 2 = 4	$0.075
4 × 2048 × 2048	1024 × 1024	4 + 1 = 5	$0.09
2 × any size	1728 × 2304 (4 MP)	2 + 4 = 6	$0.105

gpt-image-1.5 token pricing

openai/gpt-image-1.5 is billed as a per-image price plus the tokens you send in, and settled after completion ("type": "post_calculated").

amount = per-image price (see table)
       + $0.008 per 1,000 input image tokens   (reference images, image-editing only)
       + $0.005 per 1,000 prompt tokens

Result size	low	medium	high
1024 × 1024 (1:1)	$0.009	$0.034	$0.133
1024 × 1536 (2:3)	$0.013	$0.051	$0.200
1536 × 1024 (3:2)	$0.013	$0.050	$0.199

text-to-image has no reference images, so its bill is the table above plus the prompt.

What a reference image costs

input_fidelity is what drives the reference-image cost, and it defaults to high:

Reference image	`input_fidelity: low`	`input_fidelity: high`
square (e.g. 1024 × 1024, 2048 × 2048)	194 tokens — $0.0016	4,354 tokens — $0.0348
portrait (e.g. 1024 × 1536)	323 tokens — $0.0026	6,563 tokens — $0.0525
landscape (e.g. 1536 × 1024)	323 tokens — $0.0026	6,531 tokens — $0.0522

Resolution beyond that barely matters: the image is scaled so its shortest side is 512 px before it is tiled, which is why a 512 × 512 and a 2048 × 2048 square cost the same. A mask_image is not charged as a reference image, and the text the model writes alongside the image is not charged either.

gpt-image-1.5 worked examples

Request	Per-image	Reference images	Amount
`text-to-image`, 1024 × 1024, high, 20-token prompt	$0.133	—	$0.1331
`image-editing`, 1 square reference, high fidelity, low quality	$0.009	$0.0348	$0.0439
`image-editing`, 1 portrait reference, high fidelity, high quality 1024 × 1536	$0.200	$0.0525	$0.2526
`image-editing`, 3 square references, low fidelity, high quality	$0.133	$0.0047	$0.1377

Only the first row includes a prompt; the other three leave it out, since a typical prompt adds well under $0.0005. Every amount is rounded up to the next $0.0001.

LLM token pricing

LLM models (chat, messages, responses) are billed per token rather than per request. Rates are listed on each model’s page under sunra.ai/models and readable programmatically from GET /v1/pricing/model/{model_id}/endpoint/llm. A model’s rate card carries one rate per token bucket. The common buckets are:

Bucket	What it covers
Input	Prompt tokens the provider processed fresh
Output	Tokens the model generated, including reasoning tokens where a model bills them as output
Cache read	Prompt tokens served from a provider’s prompt cache
Cache write	Prompt tokens written into the cache, on providers that charge for it. Models offering an extended one-hour cache (`cache_control` with `"ttl": "1h"`) price those writes separately

Cache reads are billed at the cache-read rate and are removed from the input bucket, so a cached token is charged once, at the lower rate. For deepseek-v4-flash the cache-read rate is $0.0028 per 1M tokens against an input rate of $0.14 — 50× cheaper; for deepseek-v4-pro it is $0.003625 against $0.435. A model with no cache-read rate on its card bills cached tokens at its input rate. You do not need to send anything to opt in — see prompt cache hits for how hits are reported back to you. A request whose prompt is 98,695 tokens with 96,128 of them served from cache settles as three separate lines, and the input line counts only the 2,567 tokens that were not cached:

Bucket	Tokens	Rate per 1M	Amount
Input	2,567	$0.14	$0.00035938
Output	472	$0.28	$0.00013216
Cache read	96,128	$0.0028	$0.00026916
		Total	$0.00076070

Unlike most multimodal endpoints, an LLM request cannot be priced before it runs — the token count is not known until the model answers. Credits are reserved at submission from a conservative estimate of your prompt, and the reservation is settled against actual usage when the request completes; the difference is released. Your billing history shows the settled amount. Streamed requests that end early are billed for the output actually delivered to you, and requests that fail are not billed at all — see Output limits and stream lifetime.

Overview

Platform

Multimodal

LLM

Client Libraries

Pricing API

Paging the pricing list

How price rules are evaluated

Seedance video token pricing

How tokens are counted

Billed input seconds

Worked examples

Draft mode (Seedance 2.5)

MiniMax H3 family per-second pricing

Reference-to-video input materials

H3 worked example

Topaz Hyperion 2.5 SDR-to-HDR pricing

Input limits

Hyperion worked examples

Topaz video-upscaler pricing

Video upscaler worked examples

Qwen Image Layered pricing

FLUX.2 [pro] image-to-image pricing

FLUX.2 [pro] worked examples

gpt-image-1.5 token pricing

What a reference image costs

gpt-image-1.5 worked examples

LLM token pricing

​Pricing API

​Paging the pricing list

​How price rules are evaluated

​Seedance video token pricing

​How tokens are counted

​Billed input seconds

​Worked examples

​Draft mode (Seedance 2.5)

​MiniMax H3 family per-second pricing

​Reference-to-video input materials

​H3 worked example

​Topaz Hyperion 2.5 SDR-to-HDR pricing

​Input limits

​Hyperion worked examples

​Topaz video-upscaler pricing

​Video upscaler worked examples

​Qwen Image Layered pricing

​FLUX.2 [pro] image-to-image pricing

​FLUX.2 [pro] worked examples

​gpt-image-1.5 token pricing

​What a reference image costs

​gpt-image-1.5 worked examples

​LLM token pricing

Pricing API

Paging the pricing list

How price rules are evaluated

Seedance video token pricing

How tokens are counted

Billed input seconds

Worked examples

Draft mode (Seedance 2.5)

MiniMax H3 family per-second pricing

Reference-to-video input materials

H3 worked example

Topaz Hyperion 2.5 SDR-to-HDR pricing

Input limits

Hyperion worked examples

Topaz video-upscaler pricing

Video upscaler worked examples

Qwen Image Layered pricing

FLUX.2 [pro] image-to-image pricing

FLUX.2 [pro] worked examples

gpt-image-1.5 token pricing

What a reference image costs

gpt-image-1.5 worked examples

LLM token pricing