What will this actually cost per month? A method for pricing an LLM workload before you commit

You are picking a model for a feature that is about to ship. The provider pages give you a price per million tokens. Your product manager asks what the monthly bill will be. You do not have a good answer, because the price you were given is denominated in a unit nobody in the room thinks in. That gap is where most model-selection decisions get made badly. People pick on benchmark scores and vibes, ship, and find out the cost six weeks later when the invoice arrives with no per-feature attribution on it. The fix is four multiplications you can do before writing any code. This article walks the arithmetic with an illustrative workload, then covers the part the arithmetic misses, which is the part that usually decides the answer. Step one: describe the workload in tokens, not requests You cannot price a model against "a support assistant." You can price it against a workload described in four numbers: Calls per day. Input tokens per call, including the system prompt, retri