Most of the Bill Is Tokens You Resend
Here is the part of a production LLM bill that surprises people. Most of the tokens you pay for are not the ones your user typed. On an agentic feature they are the system prompt and the tool descriptions, resent on every step of the loop, plus a conversation history that grows and gets replayed each step, plus output tokens that are priced several times higher than input. The user's actual question is often the smallest line item on the invoice.
That matters because the shallow version of this topic ends at "use a cheaper model" or "the price is a fraction of a cent per thousand tokens." Both are true and both miss the point. The price per token is the least useful number in the whole exercise, because it tells you nothing about how many tokens a real outcome takes. A single support task handled by an agent can bill fifty thousand input tokens across its steps while returning a two-sentence answer. Quote the sticker price and you will under-forecast the bill by a large multiple.
This is a different problem from the one the LLM inference optimization lesson solves. That lesson is the serving side: how to push more tokens through a GPU you rent, using the , continuous batching, and quantization. This lesson is the spend side: the token bill itself, which is sharpest when you call a hosted API that meters you per token and where you cannot touch the GPU at all. The two are complementary. You can serve efficiently and still overpay wildly, because you are sending far more tokens than the work requires.
The plan is to decompose the bill into buckets, then pull the levers in order of leverage. By the end you will have two calculators you can run on your own numbers: one that shows the monthly bill before and after and slimming, and one that shows what a task really costs once retries and reflection are counted.