Why a million AI tokens never has one price

19 October 2026 · 7 min read

Your team agreed a story will take about a million tokens. Someone asks what that costs, and the honest answer is "it depends", which sounds like dodging. It isn't. A million tokens is a quantity, like a kilometre of road: the price depends on what kind of road. This article shows why two stories with the same token estimate can cost three times as much as each other, and how to plan for it without guessing prices in the meeting.

Three kinds of token, three prices

Most AI providers don't charge one flat rate per token. They charge for what the model reads and what it writes separately, and many give a discount for input they have seen recently.

• Input tokens are everything the model reads: the task, your instructions, the files it opens, test output, and the conversation so far. An agent re-reads much of this on every step, so input is usually the biggest share of the count.
• Cached input is input the provider has seen moments ago, such as the same instructions and files sent again on the next step. Where caching applies, it is often billed at a small fraction of the normal input price.
• Output tokens are everything the model writes: code, explanations and, on many models, its own reasoning. Output is typically priced several times higher than input.

For the examples below, take these invented prices per million tokens:

Same million, three bills

Here are three stories from one imaginary sprint. Each was estimated at 1M tokens, and each used almost exactly that. They used it very differently.

• A: the careful edit. An agent reads a large module over and over while it fixes a bug in one function. 900k input, of which 600k is cached because the same files go back on every step, and 100k output.
• B: the wanderer. The same shape of work, but the agent keeps opening new files and starting fresh sessions, so nothing is cached. 900k fresh input, 100k output.
• C: the writer. Generating a test suite and its fixtures for an existing API. It reads less and writes a lot: 600k input, 400k output.

Same estimate, same actual count, and C costs three times as much as A. Nobody estimated badly. The token number was right; it just doesn't carry the mix.

What moves the mix

• How much the work writes. Tests, migrations, documentation and boilerplate are output-heavy. A small fix in a big codebase is input-heavy. Output-heavy work costs more per million.
• Whether context gets reused. One long session that keeps sending the same files benefits from caching. Restarting sessions, switching models or reshuffling the context throws that discount away.
• Reasoning. Models that think before they answer write that thinking as tokens, and on many models it is billed as output. A hard problem can produce more reasoning than code.
• Retries. Every failed attempt is carried into the next one, so input grows with each pass. We worked through that snowball in budgeting for the retry.
• The model. A larger model can cost many times more per token than a small one, for the same count. Teams often pick per task, which is one more reason not to bake a price into the estimate.

So estimate tokens, not dollars

It is tempting to vote on cost directly. Don't. A cost vote mixes two questions, "how much work is this for the model?" and "what will our provider charge this month?", and the team can only answer the first one. Prices also change faster than your backlog: an estimate in dollars goes stale the day a model gets cheaper, while an estimate in tokens stays true.

Vote on the size in tokens, and convert afterwards, outside the meeting, with the prices you actually pay. The cards from 10k to 10M+ are explained one by one in our AI token estimation guide.

Ask one extra question when the votes agree

When the team lands on 1M without a fight, spend ten seconds on: is that mostly reading or mostly writing? The answer decides which of the three bills above you are looking at. Note it on the story, in the title ("PAY-142 retry payments (write-heavy)") or in your tracker. You don't need a precise split; "read-heavy", "write-heavy" or "mixed" is enough to pick a rate.

A worksheet for the sprint

1. Estimate tokens in the room. Turn on the AI tokens extra question next to your story points, so every story gets both numbers in one vote.
2. Download the stories. The CSV has a column for each extra question, so every story's token card is there next to its points.
3. Set a blended rate per shape. From your own past bills, or from the price list: one rate per million for each kind of story you see. With the made-up prices above, that's $1.72 for read-heavy work that caches well, $2.80 for read-heavy work that doesn't, and $5.20 for write-heavy work.
4. Multiply and add. Each story's token card times its rate gives a range for the sprint. Treat a "?" card or a 10M+ as a flag to look at, not a number to multiply.
5. Check after the sprint. Compare the forecast with the bill. If one kind of story is always off, adjust its rate, not the team's voting.

Mistakes to avoid

• One price for every million. A single rate hides a threefold spread, as the table shows. Use at least two: read-heavy and write-heavy.
• Counting only the first attempt. Retries are where budgets break. Estimate the whole story, from first prompt to merged pull request.
• Treating tokens as effort. A cheap story in tokens can still take a senior engineer an afternoon to review. Keep story points for the human work, and tokens beside them.
• Saving the dollars instead of the tokens. Keep the token estimate as the record and recompute the money when prices change.

Try it in Storyvote

Create a room, keep your points deck and add AI tokens under extra questions. Everyone votes both at once, the cards stay hidden until the reveal, and the estimates download as a CSV for your worksheet. Our guide to planning poker for AI teams shows the whole setup, and the AI estimation page sums up what the room can ask.

← All articles