Models & pricing

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

Live rates and capabilities are on GET /v1/models, under this model’s image_pricing block.

​

Rate card

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 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.

​

Output size ceiling

Requests that carry identity — subjects[], character_id, reference_image_urls or context_images — render with an output ceiling of 4,624,220 px (about 4.6 MP). A request above that ceiling is not rejected: it is scaled down to fit, preserving your aspect ratio, and the image you receive is smaller than the one you asked for. A prompt-only request has no such ceiling. It renders at the size you asked for, up to the 16,777,216 px (16.8 MP) maximum the size parameters accept. The ceiling is an area, not a per-side limit, so any aspect ratio may spend it however it likes — a 1:1 render lands near 2144 × 2144, a 3:4 near 1856 × 2480. Both are the same pixel budget. Pricing is unaffected by the ceiling: the tier is decided by your resolved requested pixels, so a scaled-down render bills the tier you were quoted, and the estimate stays exact.

​

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 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. Always read the current per-tier rate from GET /v1/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.