What this comparison can—and cannot—tell you
A model-price table can estimate an API bill only when the request shape is stated. It cannot show which model will solve a coding task best, how many retries an agent needs, or how much a particular team will spend. The figures below are a reproducible example, not a benchmark or a record of live API calls.
The comparison uses Anthropic’s listed first-party API rates checked on October 13, 2026. It covers three current models—Sonnet 5.5, Opus 5.5, and Fable 5.1—and one deliberately repetitive workload. Anthropic can change prices, so check the linked pricing page before using this for a budget.
Modelled workload: 50 repeated turns
Assume an application makes 50 requests. Every request contains 80,000 input tokens and produces 1,500 output tokens. To model reuse, assume that 76,000 input tokens are an identical, cache-eligible prefix and 4,000 are new on every turn. The first request writes the full 80,000-token prefix. Each of the next 49 requests reads the reusable 76,000-token prefix and writes the new 4,000-token suffix.
For the cached cases, assume every repeat request arrives within the chosen cache lifetime and the reusable prefix remains byte-for-byte unchanged. This is an intentionally favorable reuse pattern. A real agent may have a growing conversation, tool results, different system prompts, pauses that expire the cache, or retries that change the prefix. Those behaviors can materially raise the bill.
| Model | No prompt cache | 5-minute cache, assumptions above | 1-hour cache, assumptions above |
|---|---|---|---|
| Sonnet 5.5 | $8.75 | $1.81 | $2.23 |
| Opus 5.5 | $17.50 | $3.62 | $4.45 |
| Fable 5.1 | $43.75 | $8.13 | $10.20 |
These are totals for the 50-turn example. They exclude tools, web search, taxes, any application or hosting charges, and batch discounts. Rounded values can differ by a cent from calculations made with unrounded amounts.
How to reproduce the calculation
Prices are in US dollars per million tokens. For each model, use the input and output rates from the current pricing page, plus its cache-write and cache-read rates. The no-cache total is:
50 × [(80,000 ÷ 1,000,000 × input_rate)
+ (1,500 ÷ 1,000,000 × output_rate)]For the cached example, the first request writes the whole prefix. The remaining 49 requests read 76,000 cached tokens and write 4,000 new tokens each:
first request:
(80,000 ÷ 1,000,000 × cache_write_rate)
+ (1,500 ÷ 1,000,000 × output_rate)
49 repeated requests:
49 × [(76,000 ÷ 1,000,000 × cache_read_rate)
+ (4,000 ÷ 1,000,000 × cache_write_rate)
+ (1,500 ÷ 1,000,000 × output_rate)]Anthropic lists 5-minute cache writes at 1.25 times the model’s base input rate and 1-hour writes at 2 times the base input rate. Cache reads have their own lower rate. Applying those multipliers and the listed model rates produces the table above. The cache is not free: the initial write and each new suffix are charged.
Why the cache changes the result
In this constructed example, the repeated prefix is large and the cache is assumed to stay warm. That is why cached totals are much lower. It should not be read as “caching makes an agent 80% cheaper” in general. If requests arrive after the cache lifetime, the prefix must be written again. If the prefix changes, fewer tokens may qualify for reuse. If the task uses less repeated context, the savings shrink.
The 1-hour option costs more per cache write than the 5-minute option. It can still be useful when the pauses between requests are long enough that a 5-minute entry would expire. The right comparison is your actual timing and repeated prefix, not the cache duration alone.
Turn this example into your own estimate
- Collect a representative week of API usage, including model, input tokens, output tokens, cache writes, cache reads, retries, and tool calls.
- Separate stable instructions and reference material from conversation turns. Measure how much of the input is genuinely reused unchanged.
- Record the time between requests. This shows whether a 5-minute or 1-hour cache is relevant; it does not guarantee a hit.
- Recalculate with the current rates and your real token counts. Keep batch work separate because its eligibility and timing differ from interactive requests.
- Compare task outcomes as well as price. A cheaper completion that needs more retries or human correction may have a higher total cost.
For an application team, the most useful metric is often cost per accepted result, not cost per turn. Track whether the answer passed the relevant checks, how much review it needed, and how many follow-up calls were required. This article provides a cost model; it does not establish that one model is more accurate or productive than another.
Frequently asked questions
Did these totals come from a live coding-agent test?
No. They are calculated from a stated token pattern and published list rates. No live model requests or performance tests are represented.
Does every repeated prompt receive a cache hit?
No. Reuse depends on the cacheable prefix matching and the request arriving within the relevant lifetime. Measure cache-read tokens in your own API usage to learn what your application actually reuses.
Why is the first request treated differently?
It has no earlier cached prefix to read. In the example it writes the full 80,000-token prefix. Later requests can read the repeated part and write only the new suffix, under the stated assumptions.
Can I multiply the table by my number of monthly sessions?
Only if each session resembles this artificial 50-turn workload. For example, 1,000 identical modelled sessions would multiply each figure by 1,000, but real sessions differ in prompt size, cache reuse, output length, tool use, and retries. Use logs from your own application for a budget.
Does this compare model quality?
No. Price arithmetic says nothing about answer quality. Evaluate the same representative tasks with a documented rubric and human review before choosing a model for a workflow.
Sources and check date
Checked October 13, 2026. Prices, model availability, and feature terms can change. Verify the current rates before planning spend.