Most cost surprises are not caused by the price per token. They are caused by volume assumptions that were never written down, and by token counts that turned out to be larger than anyone estimated.
Four variables determine the bill: tokens in per request, tokens out per request, requests per month, and the model. Everything else is secondary. Write all four down with the reasoning behind them, because the reasoning is what you will revisit when the estimate turns out to be wrong.
Three things are routinely forgotten. The first is the system prompt, which is sent on every single request and is often longer than the user message. The second is retrieval context: a RAG pipeline that injects five chunks of eight hundred characters each adds meaningfully to every call. The third is retries — any pipeline that validates output and retries on failure consumes tokens for the failed attempt too.
Model choice usually matters more than optimisation. Moving a classification task from a frontier model to a smaller one can change the cost by an order of magnitude, where trimming a prompt might save a few per cent. Before optimising tokens, check whether the task needs the model you have chosen.
Build the estimate as a range rather than a single number. A low case with your expected volume and a high case with conservative token counts and a realistic retry rate will tell you more than a precise-looking point estimate. If the high case is affordable, you can stop worrying; if the low case is not, you have a design problem rather than a pricing problem.