What AI actually costs

A model is billed by the amount of text it handles. Not by the hour, not by the person, not by the seat. Every time a workflow calls a model, the provider counts the text that went in and the text that came back, and charges for both.

So the bill for an AI workflow moves with how much work goes through it. And the number that catches companies out is almost never the price per unit, which is small and keeps getting smaller. It is how many units a real month turns out to contain.

The meter

The unit is the token, the same chunk of text the context window is measured in: roughly 4 tokens for every 3 English words, so a page of ordinary prose is around 650.

Two counts, not one. The text sent to the model is counted on the way in, the text the model writes is counted on the way back, and the second is priced at several times the first, commonly around 5 times across the major providers. Writing is the expensive direction per token. Reading is usually the larger pile.

Both counts are small in isolation. A page in and a short answer out costs around a US cent on a top-tier model and a small fraction of one on the small, fast tier. Nothing about a single run looks like a budget item, which is exactly why the first real invoice is a surprise.

Example

Let’s say someone pastes a 12-page contract in and asks for a short summary. About 8,000 tokens go in and about 500 come back.

The answer is the small part of the exchange and the expensive part per token. At 5 times the rate, those 500 tokens cost what 2,500 would cost going in, so the reading still costs about 3 times the writing. Reverse the job, one line of instruction in and 5 pages of draft out, and the bill flips with it.

Why the bill surprises people

Four things push a real month well past what a pilot suggested.

Production volume is not pilot volume. A pilot is 2 people being careful on test data. Production is everyone, on live records, including the people who were never in the room. The volume does not rise in proportion to headcount either, because a tool that works gets used for things it was not scoped for. What else starts moving on that day is the subject of the production chapter; cost is the one that shows up first, because it arrives as an invoice.

Text nobody typed is still billed. The prompt a person writes is usually the smallest part of what gets sent. The standing instructions the system adds every time, the document someone pasted, the records a lookup pulled in, the descriptions of every tool the model is allowed to use: all of it goes in, and all of it is counted. A 40-word question can arrive at the model as 6,000 tokens.

Models that reason bill the reasoning. A model set to work through a problem before answering produces that working as text, and it is counted at the output rate whether it is shown in full, shown as a summary, or hidden. A 200-word answer with 2,000 words of thinking behind it is billed as 2,200 words of output, 11 times the answer alone. This is a setting on most current models rather than a separate product, which is why it gets left on by whoever built the prototype.

Every turn re-sends the conversation. A model keeps no record between turns, so the whole thread has to be sent again on each one. The cost of a long exchange does not grow with its length. It grows with the square of it.

Example

Let’s say a person works through a problem with an assistant over 30 messages. Turn 1 sends 1 message. Turn 15 sends 15. Turn 30 sends all 30.

Add those up and the session has sent 465 message-sized blocks to get 30 replies. The last reply cost 30 times what the first one did, and nothing about the session felt any different at the end than it did at the start.

What pulls the bill down

Repeated text is discounted. Text sent unchanged from one request to the next is billed at a fraction of the first-time rate by every major provider, commonly a tenth. The name for this is caching, and it is why a fixed instruction block or a standing reference document is no longer the expensive thing it was 2 years ago.

Three conditions come with it. The repeated part has to be identical, character for character. It has to sit at the front of the request, because what gets matched is the beginning. And the stored copy expires quickly, in minutes by default, so it pays where requests arrive close together and does nothing for a workflow that runs 3 times a day. There is also a small premium on the request that stores the copy, which one or two later reads pay back. The practical move is to put everything fixed at the start of the request and everything that changes at the end.

Routine work does not need the top tier. Each family ships at roughly 3 sizes, and the small one costs a fraction of the top one per page of text. Classifying, routing, extracting 3 fields and drafting a standard reply are not top-tier work, and prototypes end up there only because it is what the person building already had open.

Work that can wait is discounted. Providers charge roughly half rate for requests submitted to be answered within a few hours rather than immediately. Anything running overnight on a queue qualifies, and nothing about the output changes.

The whole curve moves down. Capability keeps arriving at lower tiers, so the same job costs less each year on the same quality. Any cost assumption fixed today reads as pessimistic within a year.

Example

Let’s say each run of a ticket-drafting tool sends 3,000 tokens of standing instructions and refund policy, which never change, plus a 400-token ticket, which does.

Cached, the fixed 3,000 bill at a tenth. The input side falls from 3,400 tokens to the equivalent of about 700, a fifth of what it was, and the change is in how the request is assembled rather than in what it does. The catch is the traffic: tickets arriving every few minutes hit a live copy, and tickets arriving twice a day pay full rate every time.

Working out the cost before building anything

An estimate takes 4 numbers, and 3 of them are already known before a line of code exists.

How many times the workflow runs in a month. How much text goes in on one run, counting the standing instructions and anything a lookup adds, not just what a person types. How much comes back on one run. And which tier the work needs.

Multiply the first by the second and third to get tokens a month. Apply the rate, then divide the monthly figure back down to a cost per run, because that is the number worth arguing about. A monthly total says nothing on its own.

Then move one number at a time to see what the answer is actually sensitive to. It is usually not the one people expect.

Example

Let’s say Northwind Industrial, the 200-person distributor, has written down what released means in each of its 2 warehouses, and now wants to cost its order-status replies before anyone builds them.

The 4 numbers. Order-status questions are 60% of the roughly 8,000 tickets support opens in a month, so 4,800 runs. Each run sends 900 words of standing instructions and reply rules, the customer’s message at about 100 words, and the order record the lookup returns at about 200, so 1,200 words in, near enough 1,600 tokens. Each run writes a reply of about 150 words, so 200 tokens. The work is routine, so the workhorse tier.

That is 7.7 million tokens in and just under 1 million out across the month. The workhorse tier currently runs at a few dollars per million tokens in and about 5 times that out, so use $2 and $10 and read the size of the answer rather than its decimals: about $15 in, $10 out, $25 for the month. Per question, half a cent.

Now move the numbers. Triple the volume and it is about $75, which changes nothing anybody decides. Turn on the reasoning setting so the model thinks for 1,500 tokens before writing the same 200-token reply, and output for the month goes from just under 1 million tokens to 8.2 million and the bill from about $25 to about $97, on identical volume. The per-run size moved the bill nearly 4 times, and it cost nothing to switch on. Tripling the business moved it 3 times and still left it under $80.

One more lever sits in plain sight: most of the 1,600 tokens going in are the same every time, so caching takes the input side to roughly a third, as long as the questions keep arriving.

What the model bill is not

The model bill is one line among several. Underneath a workflow like that sit the subscription to whatever platform it runs on, the storage and search that feed documents into it, the engineering that built it, and the person who reads the output before it reaches a customer. Where somebody checks every result, that reading time is usually larger than the model bill it is checking.

Half a cent a question, against a person spending 4 minutes on the same question, is not what decides whether the work is worth doing. It is worth knowing so that the invoice is not the first place anyone finds out.

Two directions hold while the numbers move. The rate per token falls every year. The amount of text a working system gets through rises every year, because systems get more ambitious as they get cheaper, and the second has been outrunning the first. An estimate built on today’s rate card ages badly. One built on how often the work runs and how much text each run carries stays useful, because those are facts about the business rather than about the price list.