> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aurous-labs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Models & pricing

> The Aurous Image rate card, how the pixel tier is decided, and the exact-price guarantee. Billed in Aurous credits.

Aurous Image generations are billed in **Aurous credits** at **\$0.01 per credit** (so credits = dollars × 100). The price is fixed by the output size you asked for at request time — there is no provider-side metering to reconcile afterward. This page gives the day-one rate card, how the tier is decided, and the guarantee that keeps the quote and the charge identical.

## Models

| Model              | What it does                                                             |
| ------------------ | ------------------------------------------------------------------------ |
| `aurous-image-pro` | Flagship image generation. Pixel-tiered pricing: `standard` and `large`. |

Live rates and capabilities are on [`GET /v1/models`](/api-reference/openapi#tag/models), under this model's `image_pricing` block.

## Rate card

| Tier       | Output size              | Credits per image |
| ---------- | ------------------------ | ----------------- |
| `standard` | ≤ 2,360,000 px (2.36 MP) | **6.5**           |
| `large`    | > 2,360,000 px           | **13**            |

Multiply by `count` for a multi-image request — every image in a request shares the same output size, so the same tier and rate apply to each one.

## How the tier is decided

The tier is decided by your **output pixels** — `width × height`, after any server-side snapping — not by which size preset name you sent:

* Pass a `size` preset (e.g. `2k_1_1`) or explicit `width`/`height`, and the platform resolves the output pixel count and matches it against the boundary above.
* **Omit `size` entirely** and the platform defaults to `1_5k_1_1` (1472×1472 = 2,166,784 px) — **`standard` tier**, at 6.5 credits.
* **Every `1_5k_*` preset is `standard` tier.** The largest, `1_5k_3_2` (or its `1_5k_2_3` mirror) at 1824×1216 = 2,217,984 px, is still under the boundary — every ratio at `1_5k_*` follows.
* **Every `2k_*` and `4k_*` preset is above the boundary by pixel count.** `2k_1_1` alone is 2048×2048 = 4,194,304 px, well past it — every ratio at `2k_*` and `4k_*` follows.
* **During the current migration, a small number of request shapes still settle on the previous flat per-image rate rather than the tier above.** Where that happens the charge is *lower* than the rate card, never higher, and it is disappearing as the migration completes — so treat the card as the ceiling. If you need the exact figure for a specific request, call [`POST /v1/images/estimate`](/api-reference/images/create-image) and read `estimated_cost.amount` and `breakdown.size_tier` back; the estimate is authoritative for that request and always matches what the generation bills.
* **Custom `width`/`height` snap to the nearest multiple of 32 *before* the tier check runs** — the boundary compares against the *snapped* pixel count, not the number your own `width × height` arithmetic gives you. Both sides always snap to a multiple of 32, so every reachable output is a multiple of 1024 — the boundary itself (2,360,000) is never landed on exactly. The largest reachable `standard` output is 2,359,296 px; the smallest reachable `large` output is 2,365,440 px.
* **This snap can flip your expected tier near the edge.** A `1552×1520` request computes to 2,359,040 px by hand (under the boundary — you'd budget `standard`), but snaps to 1568×1536 = 2,408,448 px and bills `large`. A `1537×1537` request computes to 2,362,369 px by hand (over the boundary), but snaps to 1536×1536 = 2,359,296 px and bills `standard`. If you're computing custom dimensions close to the boundary, snap each side to a multiple of 32 yourself before comparing against 2,360,000, or call `POST /v1/images/estimate` and read `size_tier` back rather than predicting it.
* **Free:** reference images (`reference_image_urls`, `subjects[]`, `context_images`, `character_id`) and prompt enhancement (`enhance_prompt: true`). Neither changes which tier you land in, and neither adds a line to the price.

## The exact-price guarantee

> `POST /v1/images/estimate` returns the exact price `POST /v1/images` will charge for the identical request body — there is no ceiling-vs-actual gap to reconcile for images.

* **`estimated_cost.breakdown.size_tier`** (on the estimate) and **`cost.breakdown.size_tier`** (on the generation response) name the tier your request billed at — `"standard"` or `"large"`. It's a string, not a credit amount — don't add it to reproduce `amount`. When your team has a negotiated discount, the breakdown also carries `discount_factor`: a multiplier already folded into `base`, not a separate credit amount, so don't add that either — `base` alone equals `amount`.
* Because the price depends only on your request — output size, `count`, and any team discount — and never on post-generation metering, the estimate is exact on every request shape: plain, `subjects[]`, and `context_images` alike.
* Machine-readable per-tier rates are always available at [`GET /v1/models`](/api-reference/openapi#tag/models) under `image_pricing.tiers[]` — read them live rather than hard-coding the numbers above.

## How billing works

Admitting the generation places a hold for the full price and reduces your available balance immediately. That hold is also the final charge — nothing about an image's price depends on what happens after dispatch, so there's no later reconciliation step the way there is for token-metered video. `cost.refunded: true` (with `amount: 0`) is set on a `failed` generation, meaning the full charge was refunded; if part of a `count > 1` batch fails, the difference for the images that didn't deliver is refunded automatically. A `cancelled` generation's hold is released the same way, but the response doesn't yet reflect that: `cost.amount` still shows the originally-held amount and `refunded` is not set — key off the generation's `status` field (`cancelled`), not `cost.refunded`, to detect a cancellation.

## Rates can change

Image rates are **DB-driven and may change without an `Aurous-Version` bump** — the same mutability asymmetry documented for [LLM pricing](/api-reference/chat/pricing#mutability-asymmetry-vs-images-and-videos). Always read the current per-tier rate from [`GET /v1/models`](/api-reference/openapi#tag/models) rather than hard-coding the numbers above. Each charged image snapshots the rate in force when it was created — including on an idempotent replay — so the amount you were quoted is the amount you pay.