7 July 2026 · 5 min read
The AI Spend Autopsy is a one-off report. You connect read-only keys, we analyse 90 days of usage across your providers, and you get an itemised list of savings with the arithmetic shown. It costs £99, generated and delivered immediately after payment.
This post walks through a real autopsy, run on Halcyon Labs, the fictional company that ships as Ratelytics's demo dataset, so you can see exactly what the findings look like and how each number is derived. The demo report is a fixed 30-day exhibit so its figures stay stable across releases; your own report covers 90 days. Halcyon spends £4,182.77 a month across OpenAI, Anthropic and OpenRouter. The autopsy found £818.93 a month — 37.3% of the £2,198.30 of spend those findings can actually address.
That base matters, and it is stated on the report itself. Most of a workspace's spend is not touchable by any finding: quoting the saving against all of it would understate the work, and would invite you to apply the percentage to a bigger number than it came from. So the report names the spend the findings claimed as their base, and divides by that.
This figure changed in v4.0.0, downwards. It used to read £1,107.90, and that number was wrong: findings computed independently over the same key–model pairs, so a single pound of spend could be the base of three findings at once and the report summed all three. Every autopsy now assigns each pound to at most one finding under a stated precedence. The demo lost its batch finding entirely — every pound of its overnight spend had already been claimed — and the cache finding shrank once the cache write premium was subtracted. Nothing about Halcyon's data changed. Only the arithmetic did.
| Finding | Confidence | Monthly saving |
|---|---|---|
| Right-size frontier-model workloads | MED | £405.19 |
| Stop paying for retries | MED | £205.52 |
| Cache the repeated prompt prefix | MED | £183.71 |
| Caching is on, and barely hitting | MED | £24.51 |
| Total | £818.93 |
For every key, Ratelytics computes an hourly spend baseline: the lower quartile of that key's hourly spend across the report's 90-day window. The lower quartile rather than the mean or the median, because it is the typical quiet hour — an average is dragged upwards by the very spikes we are trying to find. Across five consecutive hours, Halcyon's evals-nightly key ran at roughly nine times its £6.59 hourly baseline. Nothing shipped that day and no dataset grew. One key, one window, an order of magnitude above baseline. That shape is a retry loop: a failing request being resent, each attempt billed in full, until a timeout gives up.
The formula: saving = spike excess × 0.8. The spike excess is what the key spent above its baseline during the event: £256.90. We apply a 0.8 recovery factor because some elevated spend during an incident is legitimate (genuine reprocessing, partial successes). That gives £205.52.
Why is this monthly? Because the loop is in a nightly job and the bug does not fix itself. Until someone adds backoff and a retry cap, every transient failure re-runs the same billing event. Fixing it once removes the class of spend, not one instance of it.
This finding takes precedence over every other one, and that is deliberate. If a retry loop and a caching opportunity touch the same key, the retry finding claims that spend first: money that should never have been spent at all is not an optimisation problem, and pricing it twice under two headings is how a report ends up claiming more than the customer spends.
It is graded MED, not HIGH. The baseline is a lower quartile of hourly spend, and every provider we connect to returns usage a day at a time. With fewer than 24 hourly points for a key, "nine times the baseline" rests on a handful of numbers, and we grade what the data can actually carry.
Three of Halcyon's keys run gpt-4.1 at material volume, and on one of them the shape is unmistakable: long inputs, very short outputs, the signature of classification rather than generation. Labelling a support ticket does not need a frontier model. gpt-4.1-mini handles short-output classification at roughly one fifth of the price.
The formula: saving = unclaimed spend × price delta × 0.4. The classification traffic is £1,523.13 a month, but £256.91 of it is already the base of the retry finding above, so this finding computes on the remaining £1,266.22. The price delta between gpt-4.1 and gpt-4.1-mini is 0.8 — the mini model costs 80% less per token. We then apply a 0.4 adoption factor: only 40% of the traffic is assumed to migrate, because some requests will turn out to need the larger model and no migration ever reaches 100%. £1,266.22 × 0.8 × 0.4 = £405.19.
"Unclaimed" is the word doing the work. Before v4.0.0 this line read £1,523.13 and produced £487.40, double-counting spend the retry finding had already priced.
MED confidence: the traffic shape is observed, but "this workload will perform acceptably on the smaller model" is an assumption you should verify with an eval before switching.
Two of Halcyon's keys send the same multi-thousand-token system prompt on every single request, and the usage data shows zero cached tokens. Prompt caching is opt-in on Anthropic, and nobody opted in. Cached input tokens are billed at a 90% discount, so an identical prefix resent thousands of times a day is the cheapest fix on this list: it is a one-line change.
The formula: saving = input cost × net cache discount × 0.6. The input-token cost attributable to the repeated prefix is £499.91 a month. The 0.6 adoption factor covers cache misses: entries expire between requests, prefixes occasionally change, and not every request window keeps the cache warm. £499.91 × 0.6125 × 0.6 = £183.71.
Where 0.6125 comes from, since it is not the number the pricing pages advertise. A cache hit is billed at 0.1× the input rate — the 90% discount everybody quotes. But the entry has to be written first, and a write is billed at 1.25× the input rate on Anthropic's five-minute cache and on OpenAI from GPT-5.6. We assume one write for every three reads, which gives an effective rate of 0.25 × 1.25 + 0.75 × 0.1 = 0.3875, so a net discount of 61.25%.
That write ratio is assumed, not measured, and the report says so on the finding's face. How often a prefix gets rewritten depends on how your request frequency lines up with the cache TTL — an hour-by-hour question, on data that arrives a day at a time. If your real ratio is worse than one in four, the saving is smaller than this. It is never larger.
Before v4.0.0 this finding used the 0.9 hit discount and ignored the write premium entirely, which is how it read £269.95.
MED confidence: the repetition and the zero cache reads are observed; the realised hit rate and the write ratio are estimates.
A second cache finding, and it is not a duplicate of the one above. That one fires where the cache is not used at all; this one fires where it is used and barely returns anything — under 20% of input read back from cache. The two can never price the same key and model, because their conditions are opposites.
The formula: saving = unclaimed input cost × (60% target − observed hit rate) × net cache discount, on the same write-premium-adjusted discount as above. The fix is different too: nothing needs adopting, so this is a matter of moving the cache breakpoint after whatever varies per request, or of requests arriving inside the TTL rather than after it.
This finding needs no hourly data, which is the point of it. Three of the five original findings lean on knowing what ran when, and most providers report usage a day at a time. Four more findings were added in v4.0.0 that work on daily rows alone — this one, a model-mix drift check, and three flags: keys that went quiet, a step change in daily spend, and how concentrated the bill is on one model's price. The three flags claim no money at all, deliberately: at a day's resolution you can often see that something changed without being able to show it was waste, and pricing that would be guessing with a decimal point.
Halcyon runs its evals every night at 02:00 through the standard synchronous API, at full interactive rates. Nobody is awake. Both major providers offer a batch API at a 50% discount for work that can wait 24 hours, and a job scheduled for 02:00 is the definition of work that can wait. Until v4.0.0 this report carried that finding at £145.03/mo.
It is gone, and no data changed. Batching is last in the precedence, and by the time it ran, every pound of Halcyon's overnight spend had already been claimed — by the retry finding, and by rightsizing the frontier model those night jobs use. You cannot both move a workload to a model that costs 80% less and bank a 50% batch discount on the same pound. The old report offered you both and added them together.
If your overnight spend runs on a model with no cheaper sibling and no caching opportunity, the batch finding will appear in your report with its own arithmetic. Halcyon's does not, so it does not.
Every finding carries HIGH, MED, LOW or REVIEW confidence, and the labels have rules.
Halcyon's £818.93 is four MED findings. No LOW findings are in that number, and the fifth finding in the report is a REVIEW flag that claims no saving at all.
The retry finding reads MED rather than HIGH, and the reason is worth stating plainly: its baseline is the lower quartile of a key's hourly spend, and every provider we connect to returns usage a day at a time. With fewer than 24 hourly points for a key, "nine times the baseline" is a claim about a handful of numbers. We grade what we can actually observe, so on daily data this finding does not reach HIGH.
The autopsy costs £99, once. Sold for business use. Your report is generated and delivered immediately after payment. Because the full deliverable is provided on delivery, purchases are non-refundable once the report is delivered. If we fail to deliver your report, we refund in full. On the demo dataset the findings came to 8x the fee; on real accounts with more than one engineer and a retry loop, the ratio is usually not close.
Connect read-only keys, wait a few minutes, read the arithmetic. That is the product.