Context Is What You Pay For

Cost per token is a supplier's metric. The number that discriminates between AI tools is how much correct reasoning you get per unit of context — and the spread across tools is elevenfold.

Written by Vladimir Miroshnichenko·Published September 2, 2026·Updated September 4, 2026·5 min read

Ask a finance person what an AI coding tool costs and they will name a seat price. Ask an engineer who runs agents in production and they will name a token bill. The second number is the one that grows, and almost nobody is measuring the thing that drives it.

The unit that matters is not tokens, and it is not seats. It is how much correct reasoning you get per unit of context you pay for.

Where the bill actually comes from

In agentic coding, input dominates. The model receives a prompt, several whole files, some conventions, the previous turns of the conversation, and whatever error output came back last time — then emits a few hundred lines. The ratio of read to written is routinely twenty or fifty to one.

This has an uncomfortable consequence: your bill is mostly the cost of the model re-learning your system. Not writing code. Re-reading, on every request, the same things it read an hour ago for a different task, because the model is stateless and the repository is its only memory.

Multiply by the number of requests an agent makes to finish one piece of work, then by the number of agents, then by the number of days. Context reconstruction is not a line item on your invoice, but it is most of what you are buying.

A ratio worth tracking

Cost per token is a supplier number. Cost per answer is closer to useful. But the number that actually discriminates between tools is a ratio:

answer quality ÷ context consumed

Call it reasoning efficiency. It asks: of the material you paid to put in front of the model, how much of it contributed to being right?

Here is that ratio computed from a controlled test — one repository, fifty questions in natural English, the model and its settings held constant, answers scored blind:

What the model was given	Quality	Context	Quality points per 1K tokens
Established product knowledge	92%	8.4K	10.95
Retrieval, best in test	78%	27.4K	2.85
Retrieval, second	74%	31.6K	2.34
Code-graph tooling	69%	38.1K	1.81
Review-oriented tooling	66%	42.7K	1.55
The raw repository	58%	61.3K	0.95

The spread in the last column is much wider than the spread in the first. Answer quality varies by a factor of about 1.6 across the table. Efficiency varies by more than eleven. That is the number your invoice is sensitive to, and it is the one nobody quotes.

Two honest notes about that column. It is derived from the two measurements to its left, not measured independently — a ratio computed from real numbers is still a ratio, and calling it a measurement would be the kind of quiet inflation this genre is full of. And the comparison that matters is against the best alternative, not against the worst: 10.95 against 2.85 is about 3.8×, and that is the honest headline. Comparing against the raw repository would have produced a bigger number and a weaker claim.

Why adding context stopped working

Every team has run this experiment without meaning to. You widened the window. You pasted in more files. The answers did not improve and the bill did.

Look at the table again and the reason is visible. The systems that supplied the most context produced the worst answers. If context were straightforwardly good, that column would slope the other way.

What is actually happening is that unstructured context transfers work rather than removing it. Twelve files that might be relevant is not an answer; it is a sorting problem handed to the model, which now spends its reasoning budget deciding what matters before it can start on what you asked. Past some point, additional context is additional noise with a price attached.

The lever is not volume. It is how much the model has to reconstruct before it can begin.

What this changes commercially

If reasoning efficiency is real, it shows up in pricing — because a company whose answers cost 8.4K tokens can afford commitments a company at 42.7K cannot.

The clearest example is metering questions. If every question a customer asks costs you thirty thousand tokens of context, you have to charge for questions, or cap them, or write a fair-use clause. If a question costs you a third of that and most of the work happened once, up front, you can leave questions unmetered and charge for the expensive part instead — establishing the knowledge in the first place.

That is not a generosity decision. It is an arithmetic one, and it is available to whoever has the better ratio.

There is a second consequence, less obvious. When most of your spend is reconstruction, model upgrades do not help you as much as they should. A cheaper or faster model still has to redo the same work. When the reconstruction is already done, a better model inherits it — you get the upgrade's full benefit instead of paying it back in re-reading.

Measuring it on your own stack

You do not need a vendor to compute this. For one week:

Record total input tokens, split by task type if you can.
Count completed pieces of work — merged changes, resolved tickets, whatever your unit is.
Divide. That is your cost per completed outcome, which is the only cost that matters.
Sample twenty requests and estimate what share of the context was actually relevant to the answer.

That fourth number is usually the shock. Teams that run it tend to find that most of what they are paying to send is not contributing, and that the share does not improve with a bigger window, a newer model or a better prompt — because none of those address why the material is being re-sent at all.

Cost per token is a supplier's metric. Cost per completed outcome is yours. The distance between them is reconstruction, and it is worth measuring before you negotiate anything.

Put a number on your own workflow

Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.

Build My Business Case → Start free →

Frequently asked questions

What is reasoning efficiency in AI coding tools?

Answer quality divided by the context consumed to produce it — in practice, quality points per thousand tokens. It exposes how much of what you paid to send actually contributed to being right. In a controlled test the range across tools was more than elevenfold, while answer quality alone varied by about 1.6×, which is why the ratio discriminates and the raw score does not.

Are input or output tokens the bigger cost in agentic coding?

Input, by a wide margin — commonly twenty to fifty times the output volume. The model re-reads files, conventions and prior turns on every call and writes back only a few hundred lines. Most of the bill is the model re-learning your system rather than generating code.

Why doesn't a bigger context window reduce my AI costs?

Because unstructured context transfers work instead of removing it. The model must decide what is relevant before it can answer, so more material means more sorting, not more understanding. In measurement, the systems supplying the most context produced the worst answers — 61.3K tokens for 58% correct, against 8.4K for 92%.

How do I calculate cost per completed outcome?

Track input tokens for a week, count the units of work actually finished in that week — merged changes or resolved tickets — and divide. Then sample twenty requests and estimate what proportion of the context was relevant. That proportion, not the token price, is where the recoverable money is.

Vladimir Miroshnichenko

Founder, GitMir

Founder of GitMir, the intelligence layer that gives AI real context about a company's software. I write about AI agents, context engineering, workflow economics and keeping AI-generated work under control.

LinkedIn →

← More articles