$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.Paging the pricing list
GET /v1/pricing returns a list envelope — { "object": "list", "data": [...], "has_more": … } — and takes:
Page forward until
has_more is false:
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:
How price rules are evaluated
Theprices 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:
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
usage_key, the amount is unit_amount × that parameter’s value (for example price per second of requested duration).
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 fromGET /v1/pricing/model/{model_id}/endpoint/llm.
A model’s rate card carries one rate per token bucket. The common buckets are:
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:
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.