---
title: "So What Is the Effective Cost for a Million Tokens on Frontier Models?"
description: "The sticker price on a model card is not what you pay. Measuring cache-hit ratios from months of real usage across Sonnet 5, Opus 5, and GPT-5.6 puts the effective cost per million tokens 70-95% below list price."
canonical_url: "https://artificialcuriositylabs.ai/posts/so-what-is-the-effective-cost-per-million-tokens/"
md_url: "https://artificialcuriositylabs.ai/posts/so-what-is-the-effective-cost-per-million-tokens.md"
published_at: "2026-09-18T07:00:00.000Z"
modified_at: "2026-09-18T07:00:00.000Z"
tags:
  - "claude"
  - "llm-pricing"
  - "prompt-caching"
  - "aws-bedrock"
  - "cost-optimization"
---

Every pricing page for a frontier model shows the same two numbers: dollars per million input tokens, dollars per million output tokens. Those numbers are true and almost useless, because they describe a request that never repeats anything — no system prompt, no tool schema, no document you send twice. Real usage doesn't look like that.

I pulled the token metrics for the Bedrock model IDs I run daily traffic through — Claude Sonnet 5, Claude Opus 5, and GPT-5.6 Sol and Terra — and split every token into four buckets each provider already bills separately: fresh input, output, cache write, and cache read. Then I priced each bucket at its own rate instead of pretending everything costs the base input price. The gap between the two numbers is the whole story, and it holds across every provider I checked, not just one.

## The insight: your effective rate is a function of your cache-hit ratio, not the model card

List price answers "what does Anthropic charge." It doesn't answer "what do I pay," because what you pay is a blend determined entirely by how often your traffic hits a warm cache versus writes a new one. Two accounts running the identical model can have wildly different effective costs per million tokens depending on nothing but prompt structure — whether the system prompt, tool definitions, and repeated context are actually being reused turn over turn.

Once caching is heavy enough, the effective rate stops looking anything like the sticker price. It starts looking like the cache-read rate, because that's the bucket most of your tokens fall into.

## What the actual mix looks like

The published rate cards for all four models, confirmed against multiple independent sources this month:

| Token type | Sonnet 5 | Opus 5 | GPT-5.6 Sol | GPT-5.6 Terra |
|---|---|---|---|---|
| Input (uncached) | $2.00 / MTok | $5.00 / MTok | $4.40 / MTok | $2.20 / MTok |
| Output | $10.00 / MTok | $25.00 / MTok | $22.00 / MTok | $13.20 / MTok |
| Cache write | $2.50 / MTok (5-min TTL) | $6.25 / MTok (5-min TTL) | $5.50 / MTok (30-min TTL) | $2.75 / MTok (30-min TTL) |
| Cache read (hit) | $0.20 / MTok | $0.50 / MTok | $0.44 / MTok | $0.22 / MTok |

I checked my own account's usage across four time windows to make sure this wasn't a one-week fluke. Across a 30-day window on Sonnet 5, cache reads accounted for **93-97% of every token processed**, depending on which sub-window you slice. Fresh input and output tokens combined never crossed 1.5% of total volume in any window I checked. Cache writes ran a steady 2-5%.

Opus 5 traffic on the same account showed the same pattern — roughly **95% of tokens landing as cache hits**, over its full lifetime to date. A second Opus tier I also run, at a lower cache-hit rate of around 81%, showed the effect in reverse: fewer hits meant a visibly higher effective rate, even on paper-identical pricing.

The pattern isn't Anthropic-specific. Running the same math on GPT-5.6 Sol and Terra — OpenAI's models on Bedrock — turned up the same shape: **95.9% cache-hit share on Sol, 88.7% on Terra**. Different provider, different pricing tiers, same underlying discipline: reused system prompts and tool schemas end up as cache hits regardless of which lab built the model.

## What that does to the effective rate

Applying each bucket's own price and dividing total spend by total tokens:

| Model | Observed cache-hit share | Effective $/MTok | Savings vs. no-cache baseline |
|---|---|---|---|
| Sonnet 5 | ~94-97% | **$0.28 – $0.43** | 80-86% |
| Opus 5 | ~95% | **~$0.92** | ~82% |
| Opus (lower-cache-hit tier) | ~81% | **~$1.65** | ~67% |
| GPT-5.6 Sol | 95.9% | **~$0.70** | ~84% |
| GPT-5.6 Terra | 88.7% | **~$0.61** | ~74% |

Sonnet 5's list price is $2/$10. The number that actually shows up on the bill, once caching does its job, sits closer to a third of a dollar per million tokens — roughly 6-7x cheaper than the naive rate you'd calculate from the pricing page alone. Opus 5 tells the same story at a different tier: list price is 2.5x Sonnet's, but the effective rate compresses the same way once the cache-hit ratio gets high enough. Sol and Terra land in a similar band despite sitting on an entirely different pricing sheet — proof that the effective rate is a property of the traffic, not the vendor.

The middle column — cache-hit share — explains almost the entire gap between rows. It's not model choice driving the spread between Opus at $0.92 and Opus at $1.65, or between Sol at $0.70 and Terra at $0.61 despite Terra having the cheaper list price. It's prompt structure.

## Does this match what other people are seeing?

Roughly, yes, and the direction is the useful signal. Public benchmarks that account for caching put blended Sonnet 5 costs somewhere between $0.79/MTok (a live-traffic benchmark reporting a 79% cache-hit rate) and $1.54/MTok (an analysis using a 7:2:1 cache-weighted blend, implying something closer to a 70% hit rate). Both are well above what I'm seeing.

That's not a contradiction — it's the same relationship holding at a different point on the curve. A benchmark workload with a 70-79% hit rate should land at a meaningfully higher effective cost than a workload sitting at 95%+, and that's exactly what the numbers show. If a benchmark's methodology assumes a lower cache-hit ratio than your actual traffic, quoting its blended $/MTok figure as "the cost of Sonnet 5" will overstate your real spend by 3-5x.

## The implication

If you're forecasting spend from the pricing page, you're pricing the wrong request — and it doesn't matter which lab's page you're reading. The number that matters is your own cache-hit ratio, and it's worth instrumenting directly rather than assuming a published blend applies to your workload, or that one provider is inherently cheaper than another before accounting for how your traffic actually behaves. A coding agent replaying the same repo context turn after turn behaves nothing like a support bot handling one-off tickets, even on the identical model at the identical list price.

The unresolved question is how far this compresses before it flattens out. Cache-hit ratios in the mid-90s are already close to the ceiling — there isn't much room left between 95% and 100%. What I don't yet know is whether the next real lever is a cheaper cache-read rate, longer TTLs that reduce write frequency, or just accepting that most of the remaining cost is now output tokens, the one bucket caching never touches.