Tokenomics: Fable 5.1's reduced cache read makes it cheaper than Opus*

In May I (with substantial help from my clanker) calculated the 62.5-minute rule for keeping Claude’s prompt cache warm. The model didn’t matter because every model I compared used the same write-to-read price ratio. With the recent release of Fable 5.1, Anthropic reduced the cache read price which threw a spanner in that assumption.

Fable 5.1’s cache reads cost $0.25 per million tokens: a quarter of Fable 5’s price and half of Opus 5’s. Writes and output still cost twice as much as Opus, so the question this change poses is whether re-reading a sufficiently large conversation can pay for the more expensive tokens you keep adding to it.

tl;dr: A Fable 5.1 cache write costs as much as 50 reads, giving the old calculation a roughly 250-minute break-even at five-minute spacing. In the worked session below, Fable 5.1 also becomes cheaper than Opus 5 from call 108. That depends on both models producing the same number of billed tokens. Sonnet 5 stays cheaper throughout.

Show me the numbers

The standard API prices as of September 13th, without batch or other pricing modifiers:

Fable 5.1’s read multiplier is 0.025x base input, against 0.1x for the other three models. Limited-availability Mythos 5.1 also gets 0.025x reads. Sonnet 5’s $2 / $10 was introductory pricing, but Anthropic made it permanent on August 10th rather than raising it in September.

The same tokenizer is shared across these four models, which removes the tokenizer change from the comparison, though it doesn’t mean they’ll generate the same answer or the same number of tokens when you give them identical prompts and ask them to finish a job.

Fifty shades of… reads

The useful number is the read budget: say the prefix is already cached, W is the cost (USD) of rewriting it, R is one read, and k is the number of keepalives before the next real request:

keep warm        = k * R + R
expire + rewrite = W
 
keep warm is cheaper when (k + 1) * R < W
W / R            = 1.25 / 0.025 = 50 reads

The first write is already paid for, and the final + R matters: returning to a warm cache still costs a read, so 48 keepalives plus the real request are cheaper than a rewrite, 49 plus the real request tie it, and 50 plus the real request lose.

The Messages API supports pre-warming with max_tokens: 0, which reads or writes the cache without billing output tokens. Put an explicit cache_control breakpoint on the shared prefix, not a disposable placeholder message, and preserve the thinking configuration and output_config.effort used by the real requests. A keepalive doesn’t need an answer.

For a 100k prefix, both Fable models rewrite for $1.25. Counting all reads, including the return, makes the changed budget visible without pretending there’s an exact wall-clock crossover:

Fable 5 goes over the rewrite price on its 13th read, while Fable 5.1 doesn’t go over until its 51st.

The old smooth approximation multiplies the read budget by the TTL: 5 * 50 = 250 minutes, against 5 * 12.5 = 62.5 on Fable 5, Opus 5 and Sonnet 5. Prefix size cancels out of both ratios, and the timer still needs headroom.

Anthropic measures the TTL from the start of the request, not the end of the response. If you refresh every 4.5 minutes and return after four hours, you’ve sent 53 keepalives before the real request. That’s 54 reads, already more than a rewrite:

So 250 minutes is an estimate at near-five-minute spacing, not permission to set a four-hour timer and forget about it. The keepalive tax is cheaper, but the schedule still decides how many times you pay it. This also assumes you’ll actually return - if you abandon the session, the keepalives bought nothing.

Cheaper than Opus, sometimes

Fable 5.1 costs double Opus 5 on input, output and write pricing—only the reads are cheaper. Say a call reads N cached tokens, writes F fresh tokens and generates O billed output tokens, with prices quoted per million:

call_cost = (N * read + F * write + O * output) / 1,000,000
 
Fable 5.1 < Opus 5 when:
0.25 * N + 12.5 * F + 50 * O < 0.5 * N + 6.25 * F + 25 * O
N                            > 25 * F + 100 * O

With 3k fresh tokens and 1k output, that call becomes cheaper above a 175k cached prefix and exactly 175k is a tie. A cheaper late call doesn’t repay all the expensive early ones immediately, so the whole-session crossover needs a separate calculation.

This is a worked workload, not an actual trace from one of my sessions. Pre-warm a 20k seed and charge that write once, then send a 3k task on the first call. Each later call adds a 2k tool result and the previous 1k response, writes those 3k tokens, and generates another 1k billed output tokens. Every call hits the cache, with no idle keepalives or compactions.

The four curves price that same token workload, including the seed write, rather than assuming each model would actually take 300 calls to finish the same piece of work:

Fable 5.1 first pulls ahead on cumulative spend at call 108, which reads a 341k cached prefix. The table gives the prefix cached by the end of each call, before its newly generated output is replayed on the next request:

That’s about $22 saved against Opus 5, or 26%. Cache reads are 99.35% of input tokens in this workload, but only 57% of Fable 5.1’s bill. Sonnet stays cheaper in every column: reads cost $0.20 against $0.25, and input, writes and output are all one fifth of Fable’s prices.

The output cost still matters

That 1k output assumption does a lot of work. Fable 5.1 has always-on adaptive thinking, and current-turn thinking is billed as output alongside the visible answer. Preserved thinking from earlier turns becomes input when replayed, charged as a write or cache read rather than generated output again.

Hold incoming tool results at 2k and vary output on both models together. Fresh input on the following call is F = 2,000 + O, so the per-call crossover becomes N > 50,000 + 125 * O:

At 2k output each, Fable needs more than 300k cached tokens to win that call. At 5k each, it needs more than 675k. Those are cached prefixes, with fresh input and the next output still needing room inside the 1m context window.

Unequal output changes the comparison again. If Fable emits an extra 1k per call that Opus doesn’t, the $50 output charge and $12.50 subsequent write per million push the same-prefix crossover out by another 250k tokens, before accounting for Fable’s faster-growing history.

With 2k output on Fable against 1k on Opus, and the same 2k tool results, that threshold becomes 425k. Keeping the initial task at 3k on both models but growing their later histories at different rates puts cumulative payback at call 407, reading a 1.643m Fable prefix. That’s outside the window. It doesn’t catch up before needing to compact.

Compaction takes longer to repay

Compaction pays expensive output tokens now to save cheap reads later. Cheaper reads make that trade worse. The May calculation assumes an extra full cache read to produce a summary on the same model, output equal to the retained summary length, and a five-minute cache write for that summary.

With r = summary tokens / original tokens, the break-even is:

K = (write multiplier + output multiplier) / read multiplier
  = (1.25 + 5) / 0.025
  = 250
 
break_even_calls = (1 + K * r) / (1 - r)

That initial 1 pays for the extra full read. If compaction piggybacks a read you’ve already paid for, it isn’t an additional cost, and if generating the summary produces extra thinking tokens that aren’t retained in it, those need adding to the output bill.

The coefficient quadruples, not the whole result. At 10:1, payback needs 29 whole future calls on Fable 5.1 against nine at the standard read rate. At 2:1, 252 calls only ties the cost, and the 253rd starts saving money. All of this assumes future hits without another compaction.

Compacting can still pay off in a long session. It just needs more calls to repay itself, and the bill doesn’t tell you whether the summary kept the exact error message your clanker was going to need again.

The cache footguns

Zero-output requests have limits. Pre-warming rejects streaming, structured output, forced tool choice, batches and thinking.type: "enabled". That last restriction is on manual extended thinking, not Fable’s adaptive mode. Check the limitations before adapting a real request.

Count successful hits, not scheduled pings. Check cache_read_input_tokens and cache_creation_input_tokens, and schedule before expiry with network and scheduler headroom. A real request that hits already refreshes the TTL. A rewrite of 500k Fable tokens costs $6.25 against $0.125 for the hit, so one miss adds $6.125 to the bill.

The one-hour cache is a different up-front choice. Its write costs 2x base rather than 1.25x, but hits refresh it for another hour. Before creating either entry, the smooth cost comparison is 1.25 + 0.025 * T/5 against 2 + 0.025 * T/60, crossing at about 164 minutes on Fable 5.1, or 41 minutes with 0.1x reads.

For a four-hour gap, ideal five-minute spacing costs 2.45x base including the initial write and return read, against 2.10x with hourly spacing. Real schedules need headroom on both TTLs. This compares which entry to create, not replacing a cache you’ve already paid for or assuming a free TTL conversion.

Editing old messages can reject replayed thinking. Fable 5.1’s prefix binding covers the system prompt, tools and messages before each thinking block. A mismatch errors by default for accounts created from 31 August, while older accounts opt in, and the configured drop_block behaviour discards the block instead. Append-only history and mid-conversation system or tool changes avoid rewriting that prefix.

The lookback window isn’t a timer. Each breakpoint checks up to 20 block positions for a prior write, so appending many blocks can move the entry outside its search. Add an earlier breakpoint before that happens. A laptop sleeping through a keepalive misses the TTL instead, and no extra breakpoint fixes that.

Short prefixes still have a floor. The minimum is 512 tokens on Fable 5.1, Fable 5 and Opus 5, and 1,024 on Sonnet 5. That isn’t new to Fable 5.1. Below it, the cheap read rate doesn’t help because the prefix isn’t cached.

If Fable generates more billed output to finish the same job, the saving from its cheaper reads can disappear. The cache discount doesn’t apply to the tokens it generates.

Does finishing in fewer turns pay for it?

The other common defence of Fable’s price is that it’s the smarter model, so it finishes the job in fewer turns, and fewer turns beat cheaper turns. That can be true, but how much quicker it needs to be depends on how long the job was going to take Opus in the first place.

Using the worked workload from above, each call costs a flat amount plus a read charge that grows with every earlier call in the session:

Fable 5.1 call = 0.25 * 20k + 12.5 * 3k + 50 * 1k = $0.0925, plus $0.00075 per earlier call
Opus 5 call    = 0.5 * 20k + 6.25 * 3k + 25 * 1k  = $0.05375, plus $0.0015 per earlier call

The flat part is where Fable loses: 1.72x Opus per call, so on a short job it has to finish in about 58% of Opus’s calls, and the $0.25 seed write against Opus’s $0.125 makes that tighter still. The growth term is where Fable wins, at half Opus’s rate, so on a long job the ratio inverts.

Take an Opus session of n calls and ask how many calls Fable can make before it has spent the same money. That’s the largest m with C_fable(m) <= C_opus(n), plotted as a share of n:

At ten Opus calls, Fable has to do the job in five. At fifty it has room for forty. From call 108 it needs no turn advantage at all, which is the cumulative crossover from earlier read off the other axis. Past that, Fable can take more turns than Opus and still be cheaper, tending towards 41% more as reads come to dominate the bill: the square root of two, from the halved read growth.

The catch is the last column. Fewer turns usually means each turn does more: more thinking, longer answers, bigger edits. If that doubles Fable’s billed output to 2k per call, the flat cost becomes $0.155, or 2.9x Opus, and the growth term only drops to two thirds of Opus’s rather than half. Then Fable has to be quicker at every length on the chart: 26 calls against Opus’s 50, 67 against 100, 281 against 300. It only reaches parity around call 407, reading the 1.643m prefix from earlier, which is outside the context window.

So the argument holds, with conditions. On a short job, Fable needs to finish in roughly half the calls, and if its extra capability shows up as extra output tokens rather than skipped turns, closer to a third. On a long session the cache does the work and the turn count doesn’t have to. And the bill is per token, not per minute: a turn Fable skips saves its tool result and its output, but a turn that’s quicker on the clock and the same size in tokens saves nothing.