The Price of One Call

Input, output, and cached input are three separate tiers, with output usually the priciest. Images and video bill on a different unit entirely.

A call is not charged once. It is charged on several separate unit prices at once. Miss that structure and the only thing you can compare when choosing a model is a number on the price sheet — and that number is usually not what you end up paying.

After reading, you should be able to answer:

Which parts of one call are billed separately, and which tier usually costs most?
Why is output priced above input, and is that justified?
Why can't images and video be estimated with the text arithmetic?
What structure should a pre-launch budget follow so it is not off by an order of magnitude?

One call is charged on several separate tiers

Input price. Everything you send falls here: system prompt, conversation history, retrieved material, the question at hand. This is the highest-volume, lowest-unit-price tier, and it counts tokens, not characters.

Output price. What the model generates. Usually the priciest tier on the sheet, several times the input price.

Cache price. The opening stretch of your input that matches a previous request is billed at a discount by most providers, and the discount can be large. It is the most direct cost lever there is, and when it applies has its own article.

So the shape of the bill is: the input portion at either the input or the cache price, and the output portion at the output price. One tier is cheap but bulky; the other is expensive but depends on how much it says. That is why the two ways to save money use completely different tools — cutting input volume and cutting output volume are not the same job. Ordering on the input price per million tokens is reading half the sheet.

Some providers add other tiers: offline batch processing is cheaper but slow, realtime voice bills by the second or the minute, and new accounts often get a free allowance. None of that changes the structural picture; it only changes which tier you estimate against.

Why the output tier costs most

Because the two are not the same computation.

Input is read in one pass: the whole prompt can be processed in parallel, and repeated parts can be reused from cache. Output can only be produced one piece at a time, and every additional piece means recomputing over the sequence before it. It is compute and it is latency at once.

Three conclusions follow directly:

Make it say less, and you save money and time together. "Lead with the conclusion, keep the reasoning under three lines" — instructions like these have the highest return of any prompt you will write.
Different models use different numbers of words for the same question. A cheap model can be chatty and emit half again as much. A low unit price is not a low total price.
Analysis tasks are inherently pricier than judgment tasks. Asking for a long piece of writing is buying the most expensive tier.

Images bill by patches, video by the second

Everything so far was text. Put an image in the input and the "estimate by token count" instinct breaks down.

Images are not billed by file size or by the image. A vision model first scales the image to a size it accepts, then cuts it into fixed-size blocks, each folding into a number of tokens. So an image's price is set mainly by its resolution, not by how much text you wrote. One image often folds into the equivalent of a long passage of text. claude-vision

The expense is in the understanding itself: working out what an image shows takes far more computation than reading a passage of the same byte size — pixels carry little information per byte and a great deal of computation per byte. That also explains a familiar surprise: a few screenshots plus one question can cost visibly more than a text-only conversation.

The crucial property is that it moves in tiers, not linearly:

Scaling hits a ceiling. Past the long edge the model accepts, the image is downscaled and the extra pixels cost nothing. A full-resolution phone photo dropped in often costs little more than a compressed one — but you do not get more detail either.
Crossing a tier jumps the price. Going from an 800-pixel long edge to 1600 does not scale the token count; it steps it up. You think "a bit sharper, a bit pricier" and get "one tier pricier."
Multiple images stack. Several images in one request are each folded separately and each occupy context. Screenshot-heavy features are usually where the cost quietly escapes.

Video is a third set of units again: priced by duration, typically per second, with resolution and length each pushing the price up a tier. openai-pricing It is more expensive than images, and by a wide margin.

So the correct move is: estimate each modality with its own unit, and stop expecting one mental model to cover all of them. Text in tokens, images in resolution-derived blocks, video by duration. Mix them and the error will be an order of magnitude.

There is also a saving more effective than any price negotiation: use structured data wherever it can replace an image. To find out where an element sits or whether it is covered, an element list is cheaper and more accurate than a screenshot; to count things, one query is cheaper than counting in an image. The reasoning behind that judgment, from the mechanism side, is in Multimodal Input.

Compare models on one batch of real requests

To price two candidates against each other, the right question is not "whose unit price is lower" but which one produces the lower total on the same batch of real requests. Three things decide the answer.

One, your input-to-output ratio. Ticket classification and contract review run long inputs and short outputs; turning a pile of user feedback into a trends report inverts that, with output dominating. Put the same model into both pipelines and the blended cost can differ several times over.

Two, how talkative it is. Same question: one model answers in two hundred words, another in fifteen hundred. If you are billed by the word, the extra spend is not only on the output tier — that longer answer also returns as history in every later turn, growing the input as well.

Three, whether the cache hits. How stable your call structure is decides whether the prefix earns its discount. A pipeline with a steady prefix can cost far below the sheet price.

So compare the bill the same task produces, not the numbers on the price sheet. A cheap model that rambles easily costs more than an expensive one that stays quiet.

Budget by pipeline, not by unit price

To estimate before launch, split your calls into pipelines and price each one on its own:

One, work out the shape of a single call. For each pipeline: average input size, average output size, and how much of the input is cacheable. Do not estimate from "a few dozen tokens of input on average" — in multi-turn conversations and step-by-step tasks every step resends everything before it, so the input swells into the thousands.

Two, multiply by volume, and do not forget retries and debugging. Development, evaluation, and failed retries all generate extra calls. Leave headroom in the budget; do not treat retries as a surprise.

Three, add the pipelines and divide by total calls to get a blended unit price. That number is the one you can compare models with.

One last practice: bury the billing in your logs. Record input and output tokens on every call and total them daily. Without that data the budget stays a guess; with it, cost can be optimized like any other operating metric.

What this does not imply

It does not imply that the lowest unit price is the cheapest option. The tiers on the price sheet are structure, not a verdict; your real cost depends on your call structure — how long the input is, how much output you need, whether the cache hits, and how many images a pipeline carries.

Nor does it imply that you should call the model as little as possible. Cost is the numerator; the task is the denominator. Splitting one call into five to "save money" usually costs more. What matters is the cost per successful task, not the cost per call. That distinction matters more in cost work than any unit-price trick.

Exact prices move with the market — check the provider's current official pricing page. claude-pricing