Claude cost optimisation starts with what the bill is made of
Claude cost optimisation starts with knowing what the bill is made of. Pexon measures token shape, model mix, cache hit rate and routing across two weeks, then reports cost per team and per workload. Most of what surprises people is input tokens nobody counted, not the price per token.
Where the money goes
Four drivers, in the order we usually find them
| Driver | What it looks like on the invoice | What it usually is |
|---|---|---|
| Input volume | Output tokens look small, total is large | Context resent every turn |
| Model mix | One model doing everything | Retrieval running on a reasoning model |
| No caching | Identical prefixes billed repeatedly | A stable system prompt nobody marked |
| No attribution | One line for the whole company | No team key on the request |
The order matters. Attribution is last on the invoice and first in the fix, because until spend has an owner nobody is accountable for the other three.
Almost nobody is surprised by the price per token
They are surprised by the token count. A retrieval system resends the retrieved documents on every turn. A long system prompt is charged again with each message. Tool definitions are billed as input on every call that carries them. None of that appears in the comparison spreadsheet, because the spreadsheet compares prices and the bill is a volume.
So the first job is not optimisation. It is measurement: what is actually being sent, how often, by which application, and on whose behalf. Teams that skip this step usually optimise the wrong thing first, and the classic version is switching to a cheaper model and watching the bill stay flat.
What the two weeks contain
We work against your real traffic, not a sample, and we do not need production credentials to do it.
- Token shape per workload: input against output, and what fraction of input is context resent rather than new.
- Model mix measured against task type, and the cost per completed task rather than per token.
- Cache opportunity: which prefixes are stable enough to mark, and what the write premium costs against the read saving.
- Attribution: whether a team key exists on the request path at all, and what it takes to add one.
- A written estimate per fix against your own volumes, ranked by what it returns rather than by how easy it is.
Trade-off
An audit is a report, not a change. It costs two weeks and produces no saving on its own, and if your usage is one application on one model you can probably find the same answers yourself in an afternoon with the usage dashboard. It earns its price when spend is spread across teams and platforms and nobody can say which is which — that is a data-joining problem before it is an optimisation problem.
Where this leads
- LLM gateway for Claude — the usual answer to the attribution driver, and the one that also fixes routing
- Claude in your own cloud tenant — where the audit finds spend split across Bedrock and Vertex with no common view
- Prompt caching and batch processing — the mechanics behind two of the four drivers
Questions buyers ask
What does a Claude cost audit actually produce?
A cost figure per team and per workload, the four largest drivers ranked, and a written estimate of what each fix is worth against your own volumes. It is fixed price at €4,900 over two weeks. What it does not produce is a percentage saving quoted in advance, because that number depends entirely on how your prompts are shaped.
Why is my Claude bill higher than the token price suggests?
Usually because input tokens were never counted. A retrieval system sends the retrieved documents on every turn, a long system prompt is resent with each message, and tool definitions are billed as input on every call. The output you see is a small fraction of what is charged, and none of it appears in a price-per-token comparison.
Does switching to a cheaper model reduce the bill?
Not reliably. Anthropic documents that Claude 4.7 and later models use a newer tokenizer producing roughly 30% more tokens for the same text, so a lower per-token price can still mean a higher per-task cost. Cost per completed task is the only comparison that holds, and measuring it is part of the audit.
Is prompt caching worth enabling?
It depends on how often you re-read the same context. Anthropic prices a five-minute cache write at 1.25x the base input rate and a cache read at 0.1x, so caching pays back after a single read on the short duration. If your prompts change every call there is nothing to cache and the write premium is pure loss.
Should we wait for the September pricing change?
No, and it is a reason to audit sooner. Anthropic's introductory pricing for Claude Sonnet 5 at $2 and $10 per million input and output tokens runs through 31 August 2026, with standard pricing of $3 and $15 taking effect on 1 September 2026. If your forecast was built on the introductory rate, the shape of your usage matters more from September than it did before.
Can you audit spend across Bedrock and Vertex too?
Yes, and that is usually where attribution breaks. Each platform bills separately and neither knows about the other, so the first output of the audit is often a single figure that nobody in the company had seen before. Where a gateway already sits in front, the data is cleaner and the audit is faster.
Next step
Two weeks, fixed price, a number per team
€4,900 for the audit. You end with cost per team, the four largest drivers ranked against your own volumes, and an estimate of what each fix is worth. If the answer is that your spend is already efficient, that is what the report says.