THE DENOMINATOR / THREE ORIGINAL EXAMPLES
75% of what?
Fable 5.1 lowered a cache-read rate. Your complete token cost has five parts. The percentage only makes sense when you know what sits underneath the line.
The release is dated 1 September 2026. These are synthetic calculations using rates checked on 16 October. They are not model benchmark results.
A smaller rate.
The same million reads.
Take one million cache-read tokens. At the former rate they cost $1. At the new rate they cost $0.25. The difference is $0.75, and $0.75 divided by the original $1 is 75%.
The denominator contains cache reads alone. No output, fresh input or cache creation has entered the calculation. This statement is about a unit price, not the size of a whole workload.
If your workload has no cache reads, this particular rate change saves nothing. If the cache-read count changes between runs, even the category's total cost no longer follows this fixed-count example.
Same discount.
A bigger denominator.
Our cost ring starts with $20 in cache reads and $22.50 in other token costs. Reducing the $20 part by three quarters saves $15. The other $22.50 does not change. The new total is $27.50.
So the whole-workload saving is $15 ÷ $42.50, or approximately 35.3%. In the old bill, cache reads represented $20 ÷ $42.50, about 47.1%. Multiply that spend share by the 75% rate reduction and you get the same answer.
Use spend share, not token share. A cheap category can dominate the number of tokens without dominating dollars. Weighting the rate discount by the fraction of tokens would give the wrong result.
The discount can disappear.
Keep the original input, write and read counts. Now let the second run produce 500,000 output tokens instead of 200,000. That extra 300,000 costs $15. It exactly cancels the $15 rate saving.
Let the second run produce 600,000 output tokens instead. The usage increase costs $20. The rate effect is still −$15, but the net change is now +$5: $42.50 becomes $47.50, about 11.8% more.
This is a controlled counterexample. It does not claim that Fable 5.1 uses more output. It shows why a lower price for one token category cannot, by itself, predict the final cost of a different run.
Pick the unit before comparing the result.
A request, a completed user task and a day of traffic are different units. A task may make several requests. Compare equal numbers of similar tasks, include their retries, and keep your reporting window consistent. Otherwise the arithmetic can be exact while the conclusion is misleading.
The cost ring uses a deliberate order: first apply new rates to old counts, then apply new counts at new rates. This keeps the rate effect independent of the second run. Another decomposition order would assign the interaction between rate and usage differently, even though the final net difference stays the same.
When the old total is zero, a percentage change has no denominator. We show “No baseline spend” and keep the dollar amounts visible. When the old and new totals are both zero, we still do not invent a percentage.
Read the exact counters and calculation