How Far Model Prices Have Fallen, and How to Measure It Properly

Model prices have fallen by more than an order of magnitude, and almost every chart of it is wrong in the same way: it compares list prices for different things. This page gives the arithmetic that makes two prices comparable, and the procedure for rebuilding the series from primary sources rather than trusting anyone’s chart.

The headline is real and incomplete

The best-attested anchor pair in the whole story is OpenAI’s own list pricing. Its per-token price for the original davinci completions model was 6 cents per 1,000 tokens, which is 60 US dollars per million. When gpt-3.5-turbo was announced in March 2023 it was priced at 0.2 cents per 1,000 tokens, or 2 dollars per million. That is a factor of thirty, on one provider’s own published page, in about two years.

The incompleteness is that both of those are single numbers for models that were not doing the same job, priced before the industry split input from output, before caching discounts, and before reasoning models made the token count itself a variable. A series built by lining up headline numbers measures the headline, not the cost of getting work done.

Making two prices comparable

Modern pricing has at least four dimensions, and collapsing them requires stating a workload. The blended price is the honest single number, and it is a weighted average, not a mean of the two rates.

Blended price per million tokens, for a workload with a given mix:

  blended = (p_in * f_in + p_out * f_out)

  p_in, p_out = price per million input / output tokens
  f_in, f_out = fraction of your tokens that are input / output (sum to 1)

Worked, for a model at $2.50/M in and $10.00/M out,
on a workload that is 4 input tokens for every 1 output token:

  f_in = 0.8, f_out = 0.2
  blended = 2.50 * 0.8 + 10.00 * 0.2
          = 2.00 + 2.00
          = $4.00 per million tokens

The same model on a workload with a 1:1 mix:

  blended = 2.50 * 0.5 + 10.00 * 0.5  =  $6.25 per million

The model did not change price. The workload did.

Now add caching, which most comparisons omit and which is often the largest single effect on a real bill. If a fraction of your input is a stable prefix billed at a discount:

  effective_input = p_in * (1 - c) + p_in * d * c

  c = fraction of input tokens served from cache
  d = cache price as a fraction of the full input price

Worked at p_in = $2.50/M, 80% of input cached, cache at 10% of full price:

  effective_input = 2.50 * 0.2  +  2.50 * 0.10 * 0.8
                  = 0.50 + 0.20
                  = $0.70 per million input tokens

A 72% reduction on the input side, from a feature that does not appear
on any price-history chart.

There is a fuller treatment of the caching side in the prompt-caching savings page, and of the whole bill in how LLM pricing works.

Turning a ratio into a rate

“Prices fell thirty times” is not comparable to “prices fell four times” unless both carry a period. Convert to an annualised factor:

  annual_factor = ratio ^ (12 / months)

Worked on the anchor pair, taking the interval as 24 months:

  30 ^ (12/24)  =  30 ^ 0.5  =  5.48x per year

Over 30 months instead:

  30 ^ (12/30)  =  30 ^ 0.4  =  3.90x per year

The choice of start date moves the answer by 40%. Always state the
interval you used; a deflation rate without one is not a number.

Two structural drivers sit underneath the trend, and they behave differently. Algorithmic efficiency means a given capability needs a smaller model than it did, and sparse activation means a given model needs less arithmetic per token. Neither is a discount; both are genuine reductions in the cost of service, which is why the trend has continued through periods when hardware was scarce.

Price per token against price per task

This is the part that most price-history writing gets wrong, and it is the reason bills have not fallen thirty-fold for the people paying them.

Cost of a task  =  tokens the task consumes  *  price per token

If price per token falls 10x while tokens per task rise 5x,
the task got 2x cheaper, not 10x.

Worked. Suppose an extraction job that used to be one call:
  old:  4,000 in + 400 out, at $10/M in and $30/M out
        = 4000/1e6 * 10  +  400/1e6 * 30
        = $0.040 + $0.012 = $0.052

  new:  a reasoning model at $1/M in and $4/M out, but emitting
        3,000 hidden reasoning tokens on top of the 400 visible:
        = 4000/1e6 * 1  +  3400/1e6 * 4
        = $0.004 + $0.0136 = $0.0176

Cheaper by 3.0x, from per-token prices that fell by 10x and 7.5x.

Three things have pushed tokens-per-task up while price-per-token fell: hidden reasoning tokens, longer contexts because retrieval and long system prompts became normal, and agent loops that make many calls where an application once made one. Any honest price history has to report both series.

Rebuilding the series yourself

1. List the pricing-page URLs for each provider you care about. They are stable over years, which is what makes this work.
2. Pull historical snapshots from the Internet Archive’s Wayback Machine for each URL, one per quarter. The archive’s CDX API will list available snapshot timestamps for a URL so you can pick them programmatically.
3. Record, for each snapshot: date, model name, input price, output price, cached-input price if present, and context limit. Keep model name as free text; do not try to map models across generations at this stage.
4. Decide a workload mix and compute the blended price for every row with the formula above. State the mix at the top of the chart.
5. Plot on a logarithmic price axis. A constant multiplicative decline is a straight line on a log axis and a misleading hockey stick on a linear one.
6. Plot a second series for the cheapest model that clears a fixed capability bar — a score threshold on one benchmark, held constant. This is the series that answers “has it got cheaper to do my job” rather than “has the list price fallen”. Read what a benchmark score has to carry before choosing the bar.

Six traps in price comparisons

• Per 1,000 against per million. A factor of a thousand, and both notations are still in use. Normalise everything to per million before comparing anything.
• Batch and off-peak tiers. Asynchronous batch processing is commonly offered at a substantial discount. Comparing one provider’s batch price to another’s synchronous price is not a comparison. See batch discounts.
• Currency and tax. List prices are usually excluding VAT and in dollars. A European bill and a US price list differ by more than the exchange rate.
• Tokenizer differences. The same text is a different number of tokens under different tokenizers, so a lower price per token can be a higher price per document. This is largest for non-English text — the tokenizer language tax can be a factor of two or more.
• Image and audio tokens. Multimodal inputs are billed through a conversion rule that is not the text tokenizer, and the rule differs by provider. See image token pricing.
• Introductory and promotional pricing. A launch price is a marketing decision that may not survive. Mark promotional rows in your series rather than letting them set the trend line.