The most common way companies get their AI budget wrong is charming in its optimism. Someone runs a few queries in a demo, sees a cost of a fraction of a cent, multiplies loosely, and concludes AI is basically free. Then the real usage arrives and the invoice does not match the story. This paper is a method for estimating the bill honestly, before you commit to paying it every month.

Start with tokens, not dollars

Everything in per-token pricing rests on one conversion, and it is worth internalising. As a rough rule, English text runs about 1.3 tokens per word, so a 750-word page is roughly a thousand tokens, per OpenAI's own guidance. Treat that as approximate, not exact. Code and technical writing run higher. Other languages, including Swedish, inflate the count noticeably because the tokenizer was optimised for English. And newer models sometimes use tokenizers that produce meaningfully more tokens for the same text. So build in headroom rather than pretending the conversion is a constant.

The three multipliers people forget

A demo query is cheap. A real deployment is expensive for reasons the demo never shows you.

  • Output tokens cost several times more than input tokens across every major provider, and useful assistants generate a lot of output. Weight your estimate accordingly.
  • Retrieval over your own documents means every question quietly drags a large slab of context through the model. A one-line question can carry ten thousand tokens of retrieved material behind it, and you pay for all of them, every time.
  • Agentic workflows, where the model calls itself in a loop to finish a task, can multiply token use by ten or more against a single-shot query. This is where the scary numbers come from, and it is exactly the direction serious deployments are heading.

Any estimate that ignores these three is pricing a toy and budgeting for a tool.

A quick sanity anchor. Illustrative studies of heavy assistant use put a busy knowledge worker somewhere around fifty thousand input tokens and fifteen thousand output tokens a day. Over a working month that is roughly a million input and a few hundred thousand output tokens per person. Cheap on a small team. Run the same maths across a few hundred people using it hard, all day, with retrieval and agents, and the annual figure stops being a rounding error.

A method you can defend

Here is a way to produce a number you will not be embarrassed by later. Pick two or three real roles, not averages, and estimate their honest daily token use including retrieval and any agentic workflows. Convert to a monthly per-role figure. Multiply by how many people in each role will actually use the tool, not the whole headcount and not just the pilot group. Apply the provider's real input and output rates separately, because the blended number hides the expensive half. Add a growth factor, because usage of a tool people like goes up, not down. Then annualise. The result is usually two to five times the back-of-napkin figure the demo suggested, and it is the number worth taking to a decision.

Why this exercise favours owning the hardware, sometimes

Run this method and one of two things happens. Either the annual cloud number is modest, in which case the cloud is the right answer and you should stop reading vendor white papers like this one. Or it is large, and it recurs every year forever, and it grows. In that second case, the comparison against owned hardware, which is a fixed cost that does not scale with every extra query or every new hire, suddenly looks different. We walk through that comparison in our companion piece on the total cost of ownership of on-premise AI. The point of this paper is narrower: get the real cloud number first, because most people never do, and it is the number that decides everything else.

Figures here are illustrative and drawn from published rules of thumb and vendor rates current in 2026. Your actual usage is the only estimate that matters, which is exactly why it is worth measuring before you sign.