The estimate that never matches the invoice
The pricing page and the invoice describe two different things. The price page describes a token: $5 per million on Claude Opus 4.8, a fraction of a cent for a customer question. Your invoice describes how your product actually calls the model, and that path is longer, and far more expensive, than the token you priced. Nobody is overcharging you.
The gap is not one mysterious fee. It is a small set of specific, nameable multipliers, and once you can see them you can budget for them. Here they are, one at a time, priced out on a support chatbot running on Claude Opus 4.8.
| Item | Amount |
|---|---|
| Your estimate | $200 |
| Multi-turn context | + $1,260 |
| Your invoice | $1,460 |
What you budget vs what you are billed
Support chatbot · 10,000 conversations / month · Claude Opus 4.8 ($5 / $25 per 1M)
Modelled, not a quote. Assumptions: a 4-turn conversation; a 1,500-token system prompt plus retrieved knowledge re-sent on every turn; a ~500-token customer message and a ~700-token answer per turn. That is ~15,200 input and ~2,800 output tokens per conversation, or $760 input + $700 output across 10,000 conversations. Your numbers will differ; the shape will not.
The careful owner estimates $200 a month: 10,000 conversations, each a short question and a longer answer, priced honestly at $5 input and $25 output. The invoice is $1,460. The owner who only counted the customer question - input tokens, one turn - budgeted $25 and missed by nearly sixtyfold. Neither of them did anything wrong with arithmetic. They estimated the wrong quantity.
Trap 1: you priced the question, but the answer costs five times more
On every current Claude model, output tokens cost exactly five times input tokens. Fable 5 is $10 in and $50 out. Opus 4.8 is $5 and $25. Sonnet 5 is $3 and $15 (on an introductory $2 and $10 through 31 August 2026). The ratio never moves, and it points the wrong way for how people estimate: we price the thing we type, which is short, and forget the thing the model writes back, which is long.
In the support example the customer question is about 500 tokens and the answer about 700. Those answers alone - 700 tokens times 10,000 conversations at $25 per million - come to $175 a month, which is already seven times the entire input-only estimate of $25. If your product summarises, drafts, explains, or writes code, the output side is where your money lives, and it is the side the sticker price quietly under-weights.
Trap 2: a conversation is not a question
This is the big one, and it is the trap that turns a tidy estimate into a surprising bill. The API has no memory. It does not remember your last turn. So to continue a conversation, your application re-sends the entire thing on every single turn: the system prompt, whatever knowledge you retrieved, and the full back-and-forth so far. You are billed for all of it, again, each time the model speaks.
Walk the support conversation across four turns. A 1,500-token system prompt and knowledge snippet ride along every turn. By turn four you are also re-sending three previous questions and three previous answers. Add it up and a single four-turn conversation consumes about 15,200 input tokens, not the 500 you pictured when you looked at one question. That is roughly thirty times the input you estimated, and it is why re-sent context, not the model you chose, is the largest line on the invoice above.
It also compounds. Because every turn re-pays for all the turns before it, a conversation's total cost grows with the square of its length, not in a straight line. A ten-turn conversation does not cost ten times a one-turn conversation, it costs far more. A chat feature that feels cheap in a three-message demo can behave very differently once real users settle into twenty-message threads.
Trap 3: the thinking you pay for but never see
The model reasons before it answers, and that reasoning is billed as output whether or not you ever see it. On Fable 5 this thinking is always on: a request that returns a tidy 500-token answer might have spent several thousand tokens reasoning first, and every one of those invisible tokens is priced at the $50 output rate. The answer on your screen is the small part of what you paid for.
The same lever exists on the Opus family through the effort setting. Turn effort up and the model thinks longer and calls more tools, spending more tokens for more reliability. Turn it down and it moves faster and cheaper. Neither is wrong, but if you never chose a level you are paying whatever the default costs. If you are weighing an always-thinking model against a standard one, the honest comparison is not the two price sheets but the two token counts a real task produces - which is exactly what our Fable 5 versus Opus 4.8 breakdown gets into.
Trap 4: the same text, counted as more tokens
Here is the one that catches even careful teams. When you move to a newer model, its tokenizer - the thing that chops text into billable tokens - can count the identical text as more tokens than before. You changed a model string, added no features, kept the exact same per-token price, and the bill still went up.
| Model | Amount |
|---|---|
| Sonnet 4.6 | $900 |
| Sonnet 5 | $1,170 |
| Difference | + $270 |
Same text, same price sheet, a bigger bill
One monthly workload on the identical rate card ($3 / $15 per 1M)
The published tokenizer-drift figure (~30%) applied to a fixed volume. The same document set tokenises to ~100M tokens on Sonnet 4.6 (50M input + 50M output = $150 + $750 = $900) and to ~130M on Sonnet 5 (65M + 65M = $195 + $975 = $1,170). Same words, same rate card, +$270 a month.
Sonnet 5 counts roughly 30 percent more tokens than Sonnet 4.6 for the same words. The Opus 4.7 tokenizer runs somewhere between the same and about 35 percent heavier than Opus 4.6, depending on the content. So an upgrade that looks free on the price page can quietly raise a bill by a third. The fix is not to avoid upgrading - the newer models are usually worth it - but to re-measure your real token counts after any switch and re-budget from the new numbers, rather than assuming an identical rate card means an identical bill.
Trap 5: the attempts you never see
The clean request-and-response you imagine is the happy path. In production there are transient errors that get retried, safety refusals, and agent loops that call a tool, read the result, and call the model again. Each of those extra round-trips is more tokens on the meter, and none of them appear in your mental model of "one question, one answer".
There is real nuance worth knowing here. On Fable 5, a request that is refused before it produces any output is not billed at all, while one refused mid-stream bills the part that already streamed. Retries are cheap to make and easy to leave unbounded, so a small bug - an agent that loops one more time than it should, a retry policy with no ceiling - shows up as a line item, not a stack trace.
The whole hidden bill on one page
Six multipliers sit between an LLM price sheet and the invoice. Five of them live in how you call the model; the sixth lives in how you schedule the work. None is a trick or a hidden fee, and each has a specific lever that flattens it.
| Hidden cost | What triggers it | Typical size | The lever that flattens it |
|---|---|---|---|
| Output priced at 5x input | Every answer the model writes | Usually the majority of the bill | Shorten answers, cap max output, drop the effort level |
| Re-sent context | The API is stateless, so history is re-sent on every turn | Total conversation cost grows with the square of the turn count | Prompt caching (reads at ~0.1x on the cached prefix) |
| Thinking tokens | Always-on reasoning (Fable 5) or a high effort setting | Can dwarf the answer you actually see | Match effort to the task, use a non-thinking tier for simple work |
| Tokenizer drift | A newer model counts the same text as more tokens | ~+30% Sonnet 4.6 to Sonnet 5 | Re-measure token counts after any model switch, then re-budget |
| Retries and tool loops | Transient errors, refusals, agent round-trips | Each failed attempt can re-bill | Idempotency plus backoff, keep tool loops bounded |
| Un-batched background work | Running latency-tolerant jobs on the live API | Full price for work that could wait | Batch API (-50% on everything) |
Most of the bill is optional
Read that table again and notice the right-hand column. Almost every multiplier has a discount sitting opposite it, and the three biggest are not "switch to a cheaper model" - they are things you can do on the model you already run.
- Prompt caching attacks the re-sent context directly. That 1,500-token system prompt you send on every turn can be cached once and then read back at roughly a tenth of the input price on every later turn. There is a small one-time premium to write the cache, so it pays off precisely when you reuse the same context a lot, which is exactly what a chat feature does.
- The Batch API takes 50 percent off everything for work that can tolerate a little latency - overnight summaries, bulk classification, anything a user is not waiting on in real time.
- Right-sizing the model and the output - sending the easy half of your traffic to a cheaper tier, capping answer length, choosing an effort level on purpose - trims the 5x output side of the bill without changing a single answer users care about.
Stacked in the right order these can cut a bill by more than half without downgrading the experience, which is a whole article of its own. If you are still at the stage of deciding whether an AI feature is worth building at all, the honest starting point is the same one this piece argues for: estimate from the real call path, then compare it against what the task is worth. Our guide to practical AI automation for smaller businesses is a good next stop.
