We moved our AI operator to Claude Fable 5.1 the day after release and tracked it for a week

At about 14:50 on 2 September 2026 we moved the AI operator that runs our businesses from Claude Fable 5 to Claude Fable 5.1, the day after Anthropic released it. Then we spent seven days counting, because "the new model is cheaper" is a vendor claim, not a result.

Anthropic published Fable 5.1 on 1 September 2026 and was specific about where the saving comes from: "Cache reads now cost 75% less, or $0.25 per million tokens", and "For typical workloads, costs are reduced by around 25% relative to Fable 5. For complex coding and highly agentic tasks, the savings could be up to around 45%." That is a real change to how the model is billed. It is not evidence about our operation.

We wrote the pass mark down before we switched

Two criteria, fixed on 2 September so they could not move later.

Affordable meant Fable tokens per day at or below the pre-switch baseline of 89.3M a day for comparable work, and the rate limited API error count staying at zero across the window, against a baseline of zero.

Beneficial meant affordable, plus at least one positive signal on the kind of work we actually do: visibly better output, fewer retries, no new regressions.

The rate limit test is the one that matters most here. We pay for this through a flat subscription rather than per token, so the thing that can actually stop work is being throttled, not an invoice. A model that halves the price and doubles the draw can still leave you waiting on a rate limit.

What seven days showed

Measurements come from our own tracking note, where a script regenerates the table from the daily usage logs rather than anyone typing figures in. The baseline row was measured on 2 September over 26 August to 1 September. The post-switch figures cover the seven full days 3 to 9 September, re-verified at source on 10 September.

On the first row alone the upgrade fails the test: 160.8M tokens a day is 1.8 times the baseline, well over the line we set. Read the second row and the first one stops being about the model. Total draw across every model we run more than doubled, and Fable's share of the cost fell from 79% to 64%. That week contained three heavy build days, each of which ran review loops on other models as well, so the token rise tracks the work, not the upgrade. Say it plainly: the affordability line as we wrote it on 2 September was not met on its own terms. It set a token ceiling for comparable work, and the work was not comparable; the second row shows the workload moved, and the criterion had no way to measure that. That is a flaw in the criterion we set, recorded here rather than quietly re-scored.

We flagged that confound in the same note before we knew which way the numbers would go, which is the only reason we can use it now.

The third row is the one workload cannot explain away. Volume nearly doubled and the rate limit counter read zero all week, with no throttling warning recorded by hand either, and the baseline week had none of that kind. One caveat stays attached: that counter has never yet been seen to fire, so we read it alongside the hand log, never alone. On 10 September the verdict was recorded as keep, on the third row alone: no rate limit pressure at nearly double the volume. None of the three positive signals we had written down under beneficial was measured. Nothing was flagged as a regression, but an absence of flags in a week when nobody was running a regression check is not a measurement, so it does not count. The verdict is that the switch showed no rate limit pressure in practice, not that it is proven beneficial.

The dollar figures are arithmetic, not a bill

Our tooling reports an API equivalent cost for the Fable model alone of $119.53 a day after the switch against $144.55 before, a 17% fall while doing 1.8 times the tokens. It is list price arithmetic produced by ccusage, a usage tool we pinned locally at version 20.0.20 on 2 September. That version fetches its price list live at run time, and we checked that the list carried the new cache read rate for the new model; the tool's own offline snapshot predates the release and does not know the model at all. It is not what we pay. We pay a flat subscription, so that figure is a usage index for comparing one week with another using the same tool.

Even taken at face value, it proves nothing. Cache reads were 93% to 97% of our daily token draw on every day of the window, by the same tool's daily breakdown, and Fable 5.1 prices cache reads at a quarter of the old rate. The cost had to fall. A number that must fall by arithmetic cannot be used as evidence that a decision was right.

What we are not claiming

We are not claiming the output got better. We did not measure it.

Nothing in a usage log addresses quality. Answering that question properly needs a set of tasks run on both models with an answer key withheld, marked by a reviewer who does not know which model produced which output. That is the protocol the question needs. We did not run it here, so the honest verdict on benefit is that it was not disproven rather than that it was shown.

If you are running this test on your own business

Take a baseline week before you switch, write the pass and fail lines down while you still do not know the answer, and count throttling separately from cost, because throttling is what stops work. If the week after was not the same kind of week, say so in the write up.

It took one script, a table and eight days end to end, seven of them measured, and it is the same shape of question we work through in an AI Operations Day. That one starts with a free fit call. On the page: "The AI Operations Day costs £750 per day on site. If you proceed with a qualifying pilot or build within 60 days, the full fee is credited against it."

If you are still deciding which tier of AI subscription your business needs, our guide to free versus business versus enterprise versus API covers what actually separates the tiers, which is data handling rather than features. The operation being measured is described on Ross Gordon's page.

Questions we get asked

How do you tell whether a new AI model is worth switching to?

Measure two things over a fixed window that you define before you switch: whether you hit rate limits, and how many tokens a day the work draws against a baseline from before the change. We ran a seven day window on our own AI operator, 3 to 9 September 2026, after switching on 2 September, and the rate limit counter read zero at 1.8 times the baseline token volume, with no throttling warning logged by hand either. That counter has never yet been seen to fire, so we do not read it alone. A headline price cut is the weakest evidence available, because with cache heavy usage the arithmetic falls whether or not the model is any good.

Did Claude Fable 5.1 produce better output than Fable 5 for you?

We did not measure that, so we do not claim it. The week of tracking measured usage and rate limit pressure, not quality, and no usage log can tell you whether reasoning or writing improved. Answering it properly needs a paired set of tasks run on both models with the answer key withheld and the results judged cold, which we have not done for this upgrade. Nothing was flagged as a regression in the eight days after the switch, but nobody was running a regression check that week, so we do not count that as evidence either way.

What should a small business measure when a new AI model launches?

Rate limit incidents first, because that is the test your workload cannot fudge: if volume nearly doubles and nothing is throttled, you have not hit the limit yet, provided you are reading a counter you have seen fire, or a hand log next to it. Whether that means real headroom is a separate question, and one we have not answered. Then tokens per day against a baseline from the week before, read next to the kind of work you actually did that week. Treat any list price figure your tooling reports as a usage index rather than a bill if you pay a flat subscription. And write the pass and fail criteria down before you start, so they cannot move afterwards.