Two Fable 5.1 cost audits, opposite conclusions, one explanation that reconciles them

Fable 5.1 came out this week and two people independently measured what it costs. They disagree by a factor of about four, and both are right.

A MineBench run of 15 identical Minecraft builds put Fable 5.1 at $147.55 total against Fable 5's $54.93. Average inference time went from 18m 04s to 40m 12s. Output size barely moved, 34.07 MiB average against 30.65 MiB, so the operator attributes the gap to much longer reasoning rather than more produced code. Anthropic's advertised per-token API pricing is identical for both models. So if you budgeted 5.1 off the price list you're 2.7x under.

Then a developer audited 22,022 of their own API calls across both models and found the opposite. Tokens per prompt up about 31%. Cost per prompt down, from $1.52 on Fable 5 to $1.05 on 5.1. The reason is that nearly all the extra token volume is cache reads, and 5.1 bills cached reads at 25% of what Fable 5 charged.

Both datasets are quantitative, both are from operators with skin in it, and the reconciliation is mechanical. If your workload has high cache hit rates, the 75% cache-read discount swamps the extra reasoning volume and you come out ahead. If your workload is a cold long-horizon build with a mostly-fresh context each turn, you pay full freight on a lot more thinking tokens and you come out 2.7x behind. MineBench's fifteen Minecraft builds are the cold case. A developer's daily API loop against a stable codebase is the warm case.

A third data point sits alongside: a user reported Fable 5.1 spawning 126 subagents and burning 8.4M tokens on a five-file internationalization audit. Single anecdote, 48 comments, no controlled measurement. But it points the same direction as MineBench: 5.1 fans out and thinks more, and if nothing caps that, the bill follows.

So the recommendation. Don't budget agent runs off list prices, budget off your own measured cache hit rate. Anthropic's own Fable 5.1 guide now says the cheaper cache reads mean compacting early may no longer be the right cost-intelligence tradeoff, and tells you to experiment with later compaction points, which inverts the standard advice everyone including me has been giving for a year. And cap subagent fan-out explicitly in your orchestrator config. Not because 126 agents is always wrong, but because you should have chosen that number rather than discovered it in a bill.

The thing I don't know: how any of this maps onto subscription usage bars. The 22,022-call auditor says the same thing, that he can't measure it from transcripts. Neither can I. Two people measuring API dollars and neither able to see what the same workload does to a Max plan's quota is a real gap in what any of us can advise.