Why do LLM bills keep rising while token prices fall?

Both things are true at once, and that is what makes the question hard to answer from a pricing page.

A bill is two numbers multiplied together: tokens consumed, and price per token. Vendors publish the second number, compete on it, and cut it. Nobody publishes the first, because it depends on your workload. The first number has been rising faster than the second has been falling.

What follows are the mechanisms, in rough order of how much they move a mid-market bill, with the figures they rest on and where those figures come from.

The one nobody announces: the tokenizer changed

Start here, because it is the cleanest case and it is documented rather than inferred.

A tokenizer decides how text is cut into billable units. Change it, and the same prompt costs a different amount at an unchanged price.

Anthropic's pricing documentation, read in August 2026, states plainly:

Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer that contributes to their improved performance on a wide range of tasks. This tokenizer produces approximately 30% more tokens for the same text.

Now put that beside the published rates. As of August 2026, Claude Opus 4.6 and Claude Opus 4.7 are both listed at $5 per million input tokens and $25 per million output tokens.

	published input rate	published output rate	tokens for the same text
Claude Opus 4.6	$5 / MTok	$25 / MTok	baseline
Claude Opus 4.7	$5 / MTok	$25 / MTok	approximately 30% more

A team that moved between those two models changed nothing about its prompts, saw no price change announced, and received a materially larger invoice. The disclosure exists. It is a note under a pricing table and a tooltip on a comparison chart. It is accurate, it is public, and almost nobody reads it before a migration.

This is the general shape of the problem. The price is the advertised number. The token count is the one that moves, and it moves for reasons buried in release notes.

Output costs five times input, and models now write more

Across the whole published range in August 2026, the output rate is exactly five times the input rate:

model	input / MTok	output / MTok
Claude Haiku 4.5	$1	$5
Claude Sonnet 5	$3	$15
Claude Opus 5	$5	$25
Claude Fable 5	$10	$50

That ratio is the reason output growth hurts disproportionately. Anything that lengthens a response is billed at the expensive rate.

Two things have lengthened responses. Reasoning tokens are output tokens, and on current models reasoning is frequently on by default rather than opt-in. Agentic products also narrate: progress updates between tool calls, summaries at the end, explanations of what is about to happen. Each of those is output.

None of that is waste in itself. It is often what makes the result usable. It is simply billed at five times the rate of the input that prompted it, and it grew without a line item appearing on anyone's invoice to say so.

Caching: a 12.5x swing that fails silently

This is the largest single-factor swing available, in either direction.

Prompt caching lets a repeated prefix, a long system prompt or a document, be processed once and reused. The published multipliers relative to the base input rate, as of August 2026, are:

operation	multiplier	effect at $5 / MTok
cache read (hit)	0.1x	$0.50 / MTok
cache write, five minute	1.25x	$6.25 / MTok
cache write, one hour	2x	$10 / MTok

Working correctly, a repeated prefix costs a tenth of list. That is the promise, and it holds.

The failure mode is where the money goes. Caching is a prefix match: any byte change anywhere in the prefix invalidates everything after it. A current timestamp in the system prompt header. A request identifier. A user name interpolated near the top. Non-deterministic serialisation of a JSON block. Any one of those means every request writes a new cache entry and no request ever reads one.

The cost of that mistake is 1.25x instead of 0.1x on the affected tokens. A factor of 12.5, applied to what is usually the largest block of input in the request.

There is no error. No warning. Nothing fails. The only signal is in the usage object returned with every response: if the cache read token count stays at zero across repeated requests that should share a prefix, caching is not working. Almost nobody looks, because nothing tells them to.

Agentic patterns multiply the whole thing

Chat bills roughly linearly with conversation length. Agentic work does not.

One user request becomes many model calls. Each call resends the conversation so far, so input accumulates as the task progresses. Tool results, search output and file contents enter the context and stay there for the remainder of the conversation, billed again on every subsequent turn.

Fixed overhead attaches to each call too. Published tool-use system prompt costs for August 2026 range from 286 tokens on Claude Opus 5 to 675 on Claude Opus 4.7 for a tool choice of auto, before any tool is actually called. Individual tools add more on top: the bash tool alone is listed at 325 tokens on Claude Opus 5, 4.8 and 4.7.

Server-side tools add usage charges beyond tokens. Web search is published at $10 per 1,000 searches, and the documentation notes that retrieved results count as input tokens both in the turn that fetched them and in subsequent turns. One search is charged once and paid for repeatedly.

Nothing here is unreasonable. It is simply that the unit of billing is a model call while the unit of value is a completed task, and the ratio between the two has grown by an order of magnitude.

Scheduled increases that nobody diarises

Introductory pricing expires, and the expiry is published rather than emailed.

As of August 2026, Claude Sonnet 5 carries introductory pricing of $2 per million input tokens and $10 per million output, in effect through 31 August 2026, after which the standard rate of $3 and $15 applies.

For anyone running production traffic on that model, that is a 50% increase on a known date, roughly four weeks out from the time of writing. It is disclosed in a footnote on the pricing page. It will not arrive as a notification.

Two adjacent multipliers are worth the same diary entry. Requesting US-only inference through the data residency parameter applies a 1.1x multiplier to every pricing category on Claude 4.6 and later, including cache reads and writes. On partner-operated cloud platforms, regional and multi-region endpoints carry a 10% premium over global endpoints. Neither is large individually. Both are permanent once configured, and both are usually set once by an engineer solving a compliance question rather than a cost one.

What to measure instead

The per-token price is published, falling, and useless as a control. It cannot detect any mechanism above.

Four numbers do the work:

Cost per completed task. Not per token, not per request. This is the only figure that captures the tokenizer change, the thinking spend, the caching failure and the agentic multiplication at once, and the only one that maps to a business outcome.

Cache read tokens as a share of input tokens. Available in the usage object on every response, at no cost. Zero, when a prefix is being reused, means a 12.5x overcharge on that span. This is the cheapest check on the list and the most commonly skipped.

Output tokens as a share of total tokens. Output is charged at five times input, so a shifting ratio moves the bill faster than volume alone suggests.

Model calls per user request. The agentic multiplier, stated plainly. It is the number that explains why usage grew while user counts did not.

The durable point

Every figure in this article is dated August 2026 and will move. Prices change, tokenizers change, and the introductory rate above expires this month.

The method does not change. Your bill is tokens times price, the vendor competes on price, and nobody is accountable for tokens except you. Every mechanism above is a variation on that: something increased the tokens required to do the same work, and the pricing page continued to show a falling number.

The practical consequence is that per-token price should be roughly the last thing on a cost review agenda, not the first. It is the one number already being optimised by someone else, on your behalf, in their interest.

TechNative is a FinOps Foundation Implementation Partner and works with European organisations on cloud and AI cost governance. If your AI spend is growing faster than your usage and nobody can say why, get in touch.