Claude Fable 5.1 vs Opus 5: When Caching Changes Cost

Claude Fable 5.1 costs twice as much as Claude Opus 5 for ordinary input and output tokens. Its cached input costs half as much. Both facts are true, and neither tells you which model will cost less for a complete task.

The distinction matters when a model repeatedly reviews the same specification. Most of the input can stay unchanged while the question changes. A lower cache-read rate can eventually outweigh a more expensive first request.

The word eventually carries much of the story. Cache creation, uncached instructions, reasoning, and generated answers still count.

The examples below are calculated scenarios using published rates. They separate a cheaper cached request from a cheaper completed session, then show how to check the relationship on your own workload.

Time to read: 8–10 minutes.

What changed in Fable 5.1's caching price?

Anthropic prices Claude Fable 5.1 cache reads at $0.25 per million tokens, compared with $0.50 for Claude Opus 5. Fable's ordinary input, output, and five-minute cache writes remain more expensive. A fair comparison needs all four categories. Anthropic model pricing

All rates are dollars per million tokens, checked September 5, 2026. AI Crucible's configured rates include its 20% margin. The examples below use provider API rates; multiply by 1.2 for the equivalent configured AI Crucible rates.

Does a cache hit reuse the previous answer?

A provider prompt cache reuses processing of an identical input prefix. The model still generates a new answer. AI Crucible's semantic response cache is a separate mechanism that can reuse an answer; disable that mechanism when measuring provider prompt caching. Anthropic prompt-caching documentation

The shared prefix must match, and it must meet the provider's minimum cacheable length. Anthropic's default cache lifetime is five minutes, refreshed by a hit. Measure the interval from request start, since generation time consumes part of that window.

AI Crucible already builds a stable prompt prefix across supported orchestration rounds and adds Anthropic cache breakpoints. For a cache comparison, use pasted text with an unchanged original request. Confirm cache reads in usage records rather than inferring them from a fast response.

When is a later cached request cheaper on Fable?

For equal token counts, Fable is cheaper on a fully cached follow-up only when the input savings exceed the extra output cost. Large cached documents and short answers favor that outcome. Extensive reasoning or long generated reports move the comparison toward Opus.

Let P be cached input tokens and O be billed output tokens. Assume no uncached input, no new cache writes, and standard provider rates. Include billable reasoning in O where the provider accounts for it as output.

Fable follow-up cost = (0.25 × P + 50 × O) / 1,000,000
Opus follow-up cost  = (0.50 × P + 25 × O) / 1,000,000
Fable is cheaper when P > 100 × O.

For 200,000 cached input tokens and 1,000 billed output tokens, a follow-up costs $0.10 on Fable and $0.125 on Opus. Fable is 20% cheaper for that request under these assumptions.

Increase output to 3,000 tokens and the relationship reverses. Fable costs $0.20; Opus costs $0.175. The cached document did not change, but the answer cost did.

These are calculations with equal token counts. Real models can produce different amounts of reasoning and text, so a measured comparison must use each model's actual usage.

Does a cheaper follow-up mean a cheaper session?

A cheaper follow-up does not erase Fable's higher initial cache-write cost. The first request creates the cached prefix and generates an answer. It can take many successful cache hits to recover that initial difference.

Keep the same 200,000-token prefix and 1,000 output tokens per request. Assume one five-minute cache write, followed by complete cache hits with no changed prefix or additional uncached input.

Fable first request = 200,000 × $12.50 / 1M + 1,000 × $50 / 1M = $2.55
Opus first request  = 200,000 ×  $6.25 / 1M + 1,000 × $25 / 1M = $1.275
Fable total for N requests = $2.55  + (N - 1) × $0.10
Opus total for N requests  = $1.275 + (N - 1) × $0.125

Under these exact assumptions, the totals tie at 52 requests. Fable becomes cheaper at request 53. Extra decimal places preserve the small differences in this example.

Every successive request must keep the cache alive. A cache miss creates a new write expense. This fixed-prefix scenario also excludes growing conversation history, changing system instructions, and tool results.

How do uncached instructions change the calculation?

New instructions outside the cached prefix introduce uncached input costs. Fable pays more for those tokens, reducing the savings from cache reads. A small change can matter when the difference between models is already narrow.

Let U be ordinary uncached input and assume there are no additional cache writes. The warm-request condition becomes:

Fable is cheaper when 0.25 × P > 5 × U + 25 × O
Equivalently: P > 20 × U + 100 × O.

New cache-write tokens need their own term. Do not count them once as ordinary input and again as cache creation. Use distinct billing categories from the provider's recorded usage.

For a full task, compare total spend against accepted outputs. A model that needs fewer attempts can be better value even when its individual calls cost more.

How can you check this in AI Crucible?

Run Claude Fable 5.1 and Claude Opus 5 on the same substantial text specification using Competitive Refinement. Select three rounds and Gemini 3.8 Flash as arbiter. Track the Claude calls individually; account for synthesis separately from the model-to-model comparison.

Use the supplied RelayDesk review specification, a fictional packet with 36 numbered requirements. Download it and paste its complete text into the request. Retain its exact text and hash with the recorded experiment, and verify that the provider-counted prefix clears both models' cache minimums.

Paste the specification after the following instructions in the original request. The 200,000-token worked example above is an analytical scenario, not a requirement for this run.

Review the numbered specification below for implementation contradictions.
Use only the supplied text. Cite requirement IDs for every finding.
Return at most five findings and 400 words in total.
For each finding, give the conflicting requirements and the smallest repair.
Distinguish a contradiction from missing information or a design preference.
If no contradiction is supported, say so. Do not invent one to fill the list.
SPECIFICATION:

Disable semantic response caching, context compression, and adaptive early stopping for this measurement. Record the effective settings and any automatic truncation. Provider prompt caching should remain available.

Use five fresh sessions. Check first-call cache usage instead of assuming a fresh chat guarantees a cold provider cache. If the prefix is already cached, report that session as warm or wait for expiry before collecting a cold sample.

Later rounds contain peer answers and different instructions. Their total input will grow even when the original prefix matches. Measure the cached and uncached portions independently; do not apply the idealized formula to all input tokens.

Which measurements explain the real bill?

Record cache creation, cache reads, uncached input, billed output, latency, and cost for each Claude call. Pair that ledger with a check of whether the response found a supported contradiction. A cheaper request that loses the relevant evidence is not a useful saving.

Show the complete session cost, including the arbiter, alongside the isolated Claude calls. A long synthesis or extra review round can erase a saving in the initial experts.

The supplied RelayDesk packet has five deliberately conflicting requirement pairs. Use this answer key to inspect a response, keeping it out of the prompt sent to the models:

The repair must change a requirement; naming an implementation tool does not make incompatible guarantees compatible. This creates a concrete usefulness check alongside the cache ledger.

Which model should you choose for repeated reviews?

Fable's lower cache-read price is most relevant when a large stable input supports many short, useful answers. Opus can remain cheaper over the complete session because it costs less to create the cache and generate output. The right unit of comparison is the completed task.

The worked example demonstrates a possible crossover, not an expected saving. Use the actual cache-hit rate, output usage, and number of accepted answers from your workload before choosing a model.

What should you read next?

These guides explain AI Crucible's broader cost controls and the earlier Claude comparison.

• Cost and token optimizations in AI Crucible
• Claude Fable 5's rate-limiter benchmark
• Competitive Refinement and repeated model review