LLM prices fell fast in 2026, and the cache-read price matters most

If you pay for language models by the token, the price list changed under you several times this year. Max Woolf put the OpenAI and Anthropic announcements from June to October 2026 on one timeline, and the most useful thing in it for a developer is not the headline price. It is the third number, the price of a cache read.

The timeline, as Woolf lists it

All prices are dollars per million tokens, written as input / output / cache read, exactly as in his post:

• June 26: GPT-5.6 Sol at $5 / $30 / $0.50, GPT-5.6 Luna at $1 / $6 / $0.10.
• June 30: Claude Sonnet 5 at a launch price of $2 / $10 / $0.20, made permanent on August 10.
• July 24: Claude Opus 5 at $5 / $25 / $0.50.
• July 30: GPT-5.6 Luna cut by 80% to $0.20 / $1.20 / $0.02.
• August 21: GPT-5.6 Sol cut by about 20% to $4 / $20 / $0.40, for three months.
• September 1: Fable 5.1 at $10 / $50 / $0.25, against $10 / $50 / $1 for Fable 5.
• September 3: GPT-6 Astra at $10 / $50 / $1.
• September 22: GPT-6 Sol at $2 / $10 / $0.20, GPT-6 Luna at $0.10 / $0.50 / $0.01, and Claude Opus 5.5 at $4 / $20 / $0.20.
• September 29: GPT-6.1 Sol at $2 / $10 / $0.10.

Look at Fable 5 to Fable 5.1. Input and output did not move at all. Only the cache read went from $1 to $0.25. On a normal price comparison that looks like a footnote.

Why the third number is the one that counts

Woolf's point is that when you use agents for coding, cache reads are the vast majority of what you spend, 96% to 99% of total token expenditure in his figures, because the cache holds the whole previous conversation and is read again every turn. He adds that the cache tends to be hit around 90 to 100% of the time, depending on the provider. Put together, he writes, a 75% cut in the cache-read price works out to roughly a 70 to 75% cut in the cost of using the model.

Woolf also notes that GPT-6.1 Sol's cut matched what he calls Anthropic's 5%-of-input cache-read cost. The ratio between input price and cache-read price is worth checking on any model you use, because it tells you how much a cache hit actually saves.

What I would do with this

None of what follows is from Woolf's post. It is general practice for prompt caching, which providers offer in some form, and the details differ, so check your provider's docs.

Keep the stable part first. A cache matches from the start of the prompt. System instructions, tool definitions and long reference text go at the top and stay byte-for-byte the same between calls. Anything that changes per request, a timestamp, a user name, a random ID, goes after them. One changing value near the top can turn every call into a cache miss.

Measure your own hit rate. Most APIs report cached and uncached input tokens separately in the usage data of each response. Log them and work out what share of your spend is cache reads:

// u: tokens from your usage logs, p: dollars per million tokens
function cacheShare(u, p) {
  const cost = k => (u[k] * p[k]) / 1e6;
  const total = cost('input') + cost('output') + cost('cacheRead');
  return { cacheShare: cost('cacheRead') / total,
           hitRate: u.cacheRead / (u.cacheRead + u.input) };
}

If the cache share is high, compare models on their cache-read price first. If the hit rate is low, look for the value near the top of your prompt that keeps changing.

Next step: pull a day of usage logs, run the numbers above, and see which of the three prices really drives your bill. Source: Max Woolf, "OpenAI and Anthropic cut their LLM prices by up to 80% within a few months. Why?", October 25, 2026.