Pay-as-you-go, per image, per second: estimating what one call costs

"How much will this call cost?" cannot be answered with "it's cheap", because the billing unit differs by modality: text is per token, images are per image, video is per second (some models bill per clip). The first step in any estimate is not looking up a price — it is identifying the unit.

Three units, three formulas

Text is billed per token, and input and output have separate prices:

• cost = input tokens ÷ 1,000,000 × input price + output tokens ÷ 1,000,000 × output price

With prefix caching there is a third item, the cache-read price, usually much lower than normal input — but it only applies when the prefix is exactly identical. A request with 2,000 input tokens and 800 output tokens is 2,000 × input price + 800 × output price per token; substitute the numbers from the pricing page.

Images are billed per image, often per resolution tier: cost = images × tier price. The same prompt at 1024 and at 2048 is two different prices.

Video is billed by duration: cost = seconds × per-second price, with resolution tiers again affecting the rate. Asynchronous jobs take time to finish, but the charge follows the delivered specification — check the pricing page for the exact basis.

Rules of thumb for token counts

Tokenisers differ too much for a single number, so use a range: one Chinese character is roughly 1.5–2 tokens, and one English token is roughly four characters (0.75 words). Round up when you estimate — usage is settled from the upstream usage field, and your estimate does not change the invoice.

Why longer conversations cost more

Every turn of a multi-turn conversation resends all previous messages. Turn 1 sends one copy of the context; turn 10 sends the accumulated history ten times over. That is why a harmless "continue" at the end of a long thread can carry tens of times the input tokens of the first message. If the bill climbs faster than your traffic, check for unbounded context first: a hard cap, periodic summarisation, or keeping only the last few turns is the fastest saving available.

Four costs people forget

1. System prompts and tool definitions. They are resent every turn and are often longer than the user's question. More tools means more of this.
2. Retries. Timeouts, 429s and dropped streams each produce a new billable request. Retrying without idempotency multiplies your cost by the retry count.
3. Cache misses. Putting dynamic values (timestamps, random IDs) at the start of the prompt makes every prefix unique, so the cache never hits.
4. Partial failures. Interrupted streams and cancelled jobs are usually still billed for the tokens already generated. Confirm the exact rule, but leave room for it in the budget.

A budget process that works

Estimate usage (unit × quantity), multiply by the price on the pricing page, then multiply by a safety factor — 1.5–2 covers retries and long contexts. Before launch, run the smallest possible sample: for a batch job, process 1% of the volume and calibrate your formula against a real invoice before opening the taps. In day-to-day operation, use per-key spend caps and balance alerts as a backstop so a runaway loop cannot drain the account.

Prices change, so this article contains no numbers: always take prices from the pricing page, and treat the console's invoice as the authoritative charge. For billing units and common questions see the billing documentation.