The Bill Was Bigger Than the Estimate. Here Is Why

The bill arrives and it is roughly triple the estimate. Traffic was normal. Nothing looped. The feature works exactly as designed, which is the confusing part, because the arithmetic that produced the estimate was not obviously wrong: an average prompt length, a price per million tokens, a request count.

What that arithmetic left out is that a request is not a prompt. It is five separate things concatenated, only one of which anybody wrote by hand, and the four you did not write are usually the majority. Below is one request pulled apart category by category, with real measured numbers rather than estimates.

What is actually in a request?

Five categories, and they behave differently enough that averaging across them is what breaks the forecast.

The system prompt goes out whole on every single turn. The conversation history grows monotonically, so turn ten costs more than turn one for identical work. The tool definitions, meaning every tool name, description and JSON schema, are input tokens whether the model calls them or not. Tool results are whatever your function returned, appended and resent with the next request. And the output, priced four to six times higher than input everywhere, is the one category caching cannot touch.

How much does one tool definition really cost?

Far more than anyone guesses, and there is a published measurement rather than an estimate.

Anthropic's token counting documentation works the same example twice. First, a request with the system prompt "You are a scientist" and the user message "Hello, Claude" returns 14 input tokens. Then the same style of small request, with a single tool called get_weather that takes one string parameter, returns 403 input tokens.

One tool. One parameter. A one line description. It costs roughly 389 tokens, which on that small request is about 96% of the total. That figure covers the schema, the description text and the tool use system prompt the API injects whenever any tool is present, which Anthropic prices per model separately: 286 tokens on Claude Opus 5 with a tool choice of auto, 675 on Opus 4.7.

The consequence is a design rule rather than a curiosity. Tools cost input tokens on every turn of a loop, so a twenty tool registry attached to a ten turn conversation is paying for two hundred tool exposures to execute maybe three. Expose the tools the current step can plausibly use, not the whole catalogue. If your tools are reached over a protocol rather than hardcoded, filtering them per turn is a routing decision rather than a refactor, which is one of the practical arguments in our walkthrough of running an MCP server.

What do images and documents cost?

Two orders of magnitude more than the text they often replace.

The same documentation counts a request containing one photograph plus the text "Describe this image" at 1,551 input tokens. A request containing a PDF plus a summarise instruction comes to 2,188. Set those against the 14 tokens of the plain text request and the shape of the problem is obvious.

All four token counts come from Anthropic's published examples; the dollar figures are ours, computed at the $5 per million input rate listed on the Claude pricing page and read on 29 July 2026. Rates at the cheap end move faster than that, and the 80 percent cut OpenAI made on 30 July 2026 is the reason to date every figure you rely on.

None of this argues against sending images. It argues against sending them by habit. A screenshot of a table costs more than the table as text and gives the model a harder job. A PDF that your system already has structured data for is paying twice.

Why does the same text cost different amounts on different models?

Because the tokenizer is part of the model, and it changed.

A token is not a word. Byte pair encoding, the scheme OpenAI's tiktoken library implements, splits text into common subword pieces, so "encoding" may become "encod" and "ing". The library's own description notes the encoding is reversible and lossless and that each token corresponds to about four bytes on average. That average is where the familiar rule of thumb comes from, and it is exactly as reliable as any average.

The part that catches teams out is that these schemes are not stable across model generations. Anthropic's documentation states that Claude 4.7 and later models, along with Mythos Preview, use a newer tokenizer producing roughly 30% more tokens for the same text, with the exact increase depending on the content. It then gives the migration instruction plainly: do not reuse token counts measured on an earlier model to estimate costs or context fit, and instead count the same request twice, once under each model, and compare.

Read that as a 1.3x multiplier hiding inside an apparently lateral model upgrade. A team moving from an older model to a newer one at the same headline price per million tokens has taken roughly a 30% cost increase without anything appearing on a price list.

What are the three habits that multiply the bill?

Each one has a measurable multiplier, and none of them looks like a mistake while you are doing it.

Attaching every tool on every turn. Multiplier: several hundred tokens per turn per tool set, and on small requests the measured jump was 14 to 403. In a long loop this is the largest avoidable line, because it is paid on every turn regardless of whether a tool is used.

Sending pixels where text would do. Multiplier: roughly 100x against a short text request, based on the 1,551 token photograph. Screenshots of dashboards, PDFs of invoices you already parse, images of error messages: all of these are convenient for a human and expensive for a model.

Never caching a stable prefix. Multiplier: 10x on the cacheable portion with Anthropic, where a cache read costs 0.1x base input against a 1.25x write for the five minute cache. The documentation spells out the break even, noting the five minute cache pays for itself after one read and the one hour cache after two. On DeepSeek's own pricing page the gap is steeper still: $0.003625 per million on a cache hit against $0.435 on a miss for V4 Pro, which is roughly a factor of 120.

There is a fourth habit that is less common and more expensive when it happens: rebuilding the system prompt dynamically on every request. Interpolating a timestamp or a request id into the top of the prompt invalidates the cache prefix, so the entire cacheable block is billed at full input price every time. The fix is to move anything that changes below the stable block, and it can be worth an order of magnitude on the input line.

Why does turn ten cost more than turn one?

Because a conversation is not a stream, it is a re upload. Every turn sends the entire history again, which follows directly from how a model generates one token at a time.

This is the single most counterintuitive property of the billing model, and it is worth stating without hedging: the model has no memory between requests. What looks like a continuing conversation is your code re sending everything that has been said so far, plus the new message, on every single call. Nothing is retained on the other side unless you paid to cache it.

The arithmetic that follows is quadratic rather than linear. If each turn adds roughly the same volume, then a ten turn conversation does not cost ten units of input, it costs something closer to fifty five, because turn two carries turn one, turn three carries both, and so on. Doubling the length of a conversation roughly quadruples its input cost.

Three things follow. First, compaction is not an optimisation, it is the mechanism that keeps a long session affordable, and the survey of thirteen coding agent scaffolds found seven distinct strategies for it precisely because nobody has settled the question. Second, caching matters more the longer the session runs, since the re sent prefix is exactly the part that is stable. And third, an early decision to keep the system prompt lean pays every turn thereafter, compounding in the same direction.

The practical version of this is to decide, explicitly and in code, what the history contains after turn N. Trimming the oldest turns, summarising them into a single block, or re reading state from source rather than carrying it forward are all valid answers. Doing nothing is also an answer, and it is the one that produces the surprising invoice.

What about the tokens you never wrote?

There are several, and knowing they exist is most of the battle.

The tool use system prompt is the clearest example. Anthropic publishes its size per model and the numbers are not small: 286 tokens on Claude Opus 5 with a tool choice of auto, 406 with a forced choice, and 675 and 804 respectively on Opus 4.7. That block is injected automatically whenever any tool is present, so it is paid on every turn of a tool using loop, and it fell by more than half between two adjacent model generations for reasons that have nothing to do with your code.

Individual tools then add their own overhead on top. The bash tool definition alone accounts for 325 additional input tokens on Opus 5, before a single command is run and before any output comes back.

Server side tools add a different kind of line. Anthropic prices web search at $10 per 1,000 searches on top of the tokens the results consume, and estimates a typical web page at around 2,500 tokens, a large documentation page at around 25,000 and a research paper PDF at around 125,000. A single fetch of a long document can therefore cost more input than an entire day of ordinary chat traffic.

There is one piece of good news buried in the same documentation. Tokens that Anthropic adds automatically for its own system optimisations are not billed, and the counting endpoint says so explicitly. So the gap between what you count and what you pay runs in your favour rather than against you, which is worth knowing before you spend an afternoon reconciling a small discrepancy.

Does reasoning count as input?

Partly, and the rule is more favourable than most people assume.

Anthropic's documentation is specific: thinking blocks from previous assistant turns are ignored and do not count toward your input tokens, while thinking in the current assistant turn does. So an extended reasoning trace is paid once, as output, and does not then haunt every subsequent turn as input the way ordinary message content does.

That changes the arithmetic on long conversations with reasoning enabled. The history still grows, but not by the full volume of everything the model thought along the way. It also means a reasoning budget is a per turn decision rather than a compounding one, which makes it much safer to enable than the raw token counts suggest.

How do you find out where your own tokens went?

Four steps, and the first two take an hour between them.

Log the usage block on every response. Every provider returns one, split into input tokens, output tokens, cache read tokens and cache creation tokens. Store all four against a request id. Without this split you cannot distinguish a caching regression from a traffic increase, and they look identical on an invoice.

Count one real request before and after each change, using a counting endpoint rather than a character estimate. This is how you discover that adding a tool cost you 389 tokens, or that a helpful new instruction in the system prompt cost 200 per turn forever.

Attribute by category, not by request. Sum your logged usage into the five buckets from the top of this piece. The bucket that surprises you is where the work is, and it is almost never the one you were optimising.

Then re measure after a model change, always. A migration that keeps the price per million identical can still move your bill by 30% through the tokenizer alone.

The same instrumentation feeds the per task budget that stops a runaway loop, which we described as one of the six duties of an orchestration layer, and it is the raw material for sizing a feature before you build it, which we worked through in a comparison of provider pricing against real consumption.

What should you change first?

In this order, because the effort and the payoff are inversely related here.

Cache the stable prefix. It is a configuration change on most providers, it is the largest single lever on input cost, and the break even is one or two reads.

Then trim the tool set per turn. This is a routing change rather than a rewrite if your tools sit behind a registry, and it removes hundreds of tokens from every turn of every loop. The tool list MaShop exposes is published on our MCP page for exactly this reason: a written down registry is one you can filter deliberately.

Then reduce output. Shorter formats, diffs instead of whole files, a label instead of a label with an explanation. Output is the expensive column and the only one caching leaves untouched, so every token you do not ask for is a straight saving.

Then, and only then, consider a cheaper model. Most teams do this first, discover the cheaper model needs two attempts, and conclude that the cheap model is not viable when the actual problem was that nobody had cached anything. Pricing your own workload honestly, category by category, is what stops that mistake, and it is the same discipline behind how we meter credits per build on MaShop: a bill nobody can explain is a bill nobody trusts. The same question one layer up is worth asking of any builder that resells tokens to you as credits, which is why we wrote up what a Lovable credit actually buys and what burns it fastest.