Cheap Per Token, Expensive Per Task: Why the Lowest-Priced AI Coding Model Can Cost More
Engineering teams pick AI coding models on price per token. The invoice does not arrive in tokens. It arrives in finished tasks. A model that looks 60% cheaper per token can cost more per merged PR once retries, context reloading, and correction time are counted. Here is how to measure the number that actually hits your budget.
The cheapest model per token is almost never the cheapest model per task.
That sentence sounds wrong the first time you read it. Token price is the number on every vendor pricing page. It is the number procurement compares in a spreadsheet. It is the number an engineering lead quotes when finance asks why the AI bill went up. And it is the wrong unit for the decision.
Your invoice does not arrive in tokens. It arrives in work. A merged PR. A resolved ticket. A refactor that shipped. The question that decides your budget is not what a million tokens cost. It is what one finished task cost, and a model that is cheaper per token can quietly be more expensive per task.
Why Is Token Price the Wrong Unit for AI Coding Cost?
Token price measures the input. Cost per task measures the output. Those are not the same number, and the ratio between them is not constant across models.
When you buy tokens, you are buying raw material. When you ship a feature, you are paying for however many tokens it took to get there, including the ones spent on attempts that did not work. A model priced at half the token rate that needs three attempts where a stronger model needs one has not saved you money. It has spent more tokens at a lower rate and landed on a higher total.
The pricing page cannot show you this, because the multiplier lives in your codebase, your task complexity, and your review process, not in the vendor's rate card. Two teams running the identical model on the identical token price will have different cost per task, because one has a clean codebase and tight tasks and the other has legacy sprawl and vague tickets. The token price is the same for both. The cost per finished task is not.
Pro Tip: Before your next model decision, take one recent non-trivial task and count the full token spend it took to reach a merged state, including failed attempts and re-prompts. Divide by one. That single number is closer to your real cost than any per-token rate on a pricing page.
What Does Cost Per Task Actually Include?
Cost per task is total token spend to reach a shipped outcome, divided by the number of outcomes shipped. The word total is doing the heavy lifting, because it captures four things the token rate hides.
The Four Costs Hidden Inside a Finished Task
- Retries and failed attempts · The tokens spent on generations that were wrong, discarded, or re-prompted before the working version. A weaker model spends more of these. They bill at full rate and produce nothing you keep.
- Context reloading · Every time the model needs the surrounding files, the conventions, and the prior state re-fed into the window, that is tokens. Models that hold context poorly reload more often, and a large context reload is one of the biggest single line items in a task.
- Turn count · The number of back-and-forth exchanges to get to done. More turns means more accumulated context carried forward on every message, so token spend on a ten-turn task grows faster than linearly, not slower.
- Human correction time · Not a token cost, an engineer cost, and usually the largest one. If a cheaper model ships code that takes an extra forty minutes of senior review and rework per PR, the token savings are gone several times over before the PR merges.
Add those four to the visible token spend and you have the real number. Leave them out and you are budgeting the raw material and ignoring the waste.
Why Can a Cheaper Per-Token Model Cost More Per Task?
Because the token rate and the number of tokens are inversely related in a way the pricing page never shows.
A frontier model at a higher token rate tends to need fewer attempts, hold context better, and finish in fewer turns. A cheaper model at a lower token rate tends to need more attempts, reload context more, and take more turns. When the second effect is larger than the price difference, the cheaper model wins on the rate card and loses on the invoice.
This is most visible on hard tasks. On a trivial autocomplete, almost any model finishes in one shot and the cheapest per-token option is genuinely the cheapest per task. On a multi-file refactor against a legacy module, a weaker model can burn through several failed attempts, each one re-reading the full context, and end up spending more total tokens at its lower rate than the stronger model spent at its higher one. Same finished task. Higher bill. Plus the review overhead, which does not show up in tokens at all.
The teams that get surprised here are the ones who standardized on one cheaper model for everything to save money, then watched cost per merged PR go up instead of down. They optimized the unit on the price sheet and ignored the unit on the invoice.
Token Price Versus Task Cost: What the Comparison Looks Like
The table below is the shape of the problem, not a benchmark of specific models. The point is the direction the numbers move once you change the unit.
| Cheaper model | Frontier model | |
|---|---|---|
| Price per token | Low | High |
| Attempts to working code (hard task) | More | Fewer |
| Context reloads per task | More | Fewer |
| Turns to done | More | Fewer |
| Senior review time per PR | Higher | Lower |
| Cost per finished task | Often higher | Often lower |
Every row above the last one favors the cheaper model or is neutral. The last row, the only one that hits your budget, frequently flips. That flip is the entire argument. If you stop reading at price per token, you never see it.
How Do You Measure Cost Per Task?
You need two data streams joined together: token spend from the model API or gateway, and shipped outcomes from your Git provider. Cost per task is the first divided by the second, attributed at the PR level so you can see it per model rather than as one blended monthly average.
A workable approach:
- Pull token spend per PR, not per month. A monthly total cannot tell you which model or which task type is expensive. Attribution at the PR level can.
- Join it to merged outcomes. Cost per merged PR is the cleanest single proxy for cost per task, because a merge is an unambiguous shipped result. Cost per resolved ticket works the same way for teams that track it.
- Segment by task type. Autocomplete, bug fix, and multi-file refactor have completely different cost per task profiles. A blended average hides the exact place where the cheap model is losing money.
- Watch the correction signal. Track how much AI-generated code is rewritten before merge. A rising correction rate on the cheaper model is the human cost that the token savings are quietly funding.
Pro Tip: Run cost per merged PR per model for one month before you standardize on any single model to save money. Teams that do this routinely find the cheap model is cheaper on simple tasks and more expensive on hard ones, which points to routing by task type rather than picking one model for everything.
When Is the Cheap Model Actually the Cheap Choice?
Often. This is not an argument that frontier models always win. It is an argument that the unit decides, and the unit changes with the task.
The cheaper per-token model is genuinely the cheaper choice when the work is simple and high-volume: autocompletion, boilerplate, small well-scoped edits, and anything that reliably finishes in one attempt. For that class of task the retry and context penalties barely exist, so the low token rate carries straight through to a low task cost. Sending that work to a frontier model is its own kind of waste.
The frontier model tends to win when the task is hard, the codebase is complex, or a failed attempt is expensive to catch in review. There the fewer-attempts and better-context effects outweigh the higher rate.
Which is why the right answer is usually not one model. It is routing: cheap models for the volume of simple work, frontier models for the hard tasks where attempts and review dominate. But you cannot route what you cannot measure, and you cannot measure it in tokens. You measure it in cost per task.
Key Takeaways
- Token price is the input unit. Cost per task is the invoice unit. They are not the same number, and the ratio between them changes with your codebase and task complexity, not the vendor's rate card.
- A cheaper per-token model can cost more per finished task. Retries, context reloading, and higher turn counts can spend more total tokens at a lower rate than a frontier model spends at a higher one, especially on hard tasks.
- Human correction time is the cost that never appears in tokens. If cheaper output adds senior review and rework per PR, the token savings are usually gone several times over before the merge.
- Cost per merged PR per model is the number to track. Pull token spend at the PR level, join it to merged outcomes, and segment by task type. The blended monthly average hides exactly where the cheap model loses money.
- The answer is usually routing, not one model. Cheap models for simple high-volume work, frontier models for hard tasks. You cannot route what you measure in tokens instead of tasks.
Why Teams Keep Buying on the Wrong Number
The reason token price wins the decision is that it is the only number sitting in front of everyone. It is on the pricing page. It is in the procurement sheet. It is easy to compare across vendors in ten seconds. Cost per task is none of those things unless you build the measurement, so the easy number wins by default.
The pattern I keep running into is a team that switched to a cheaper model to bring the AI bill down, reported the lower token rate up the chain as a win, and then could not explain three months later why cost per merged PR had gone up instead of down. Nobody did anything wrong at the token level. The rate really was lower. They just optimized a unit that does not appear on the invoice, and the unit that does move against them quietly.
The teams that get this right are not the ones who always buy the frontier model or always buy the cheap one. They are the ones who measure cost per finished task per model, see which class of work each model is actually cheaper for, and route accordingly. That decision is boring and it is correct, and it is invisible until you change the unit you measure in.
The price sheet is a photo of the input. Your budget is a record of the output. When those two disagree, the output is the one you are paying.
· Vukasin
How Yardstick Measures Cost Per Task, Not Per Token
Yardstick joins token spend from your AI coding tools to merged outcomes from your Git provider and displays cost per merged PR per model on a single dashboard, updated daily. The number you compare across models is the finished-task cost, not the rate card.
Because attribution is at the PR level, Yardstick shows cost per task segmented by task type and by model, so the place where a cheaper model is actually more expensive becomes visible instead of hiding inside a blended monthly average. That is the data a routing decision needs.
For teams standardizing on a model to reduce spend, Yardstick runs the cost per merged PR comparison across your real tasks first, so the decision is made on the unit that hits the budget rather than the unit on the pricing page.
To see the platform or join the early access list, visit yardstick.fi/platform or review pricing for current plan options.
FAQ
What is the difference between price per token and cost per task?
Price per token is what the vendor charges for raw model usage, listed on the pricing page. Cost per task is the total token spend required to reach a shipped outcome, such as a merged PR, divided by the number of outcomes shipped. Cost per task includes failed attempts, context reloading, and turn count, none of which appear in the token rate. A model can have a lower price per token and a higher cost per task at the same time.
Why does a cheaper per-token model sometimes cost more per merged PR?
Because a weaker model often needs more attempts, reloads context more often, and takes more turns to finish a hard task. Each of those spends additional tokens at the model's rate. When the extra token volume outweighs the lower rate, the total spend to produce one merged PR is higher than it would have been on a more capable model, even though the per-token price was lower. Human review and rework time add further cost that tokens never capture.
How do I calculate cost per task for AI coding tools?
Pull token spend attributed at the PR level rather than as a monthly total, join it to merged PRs or resolved tickets from your Git or issue tracker, and divide. Segment the result by model and by task type, because simple and complex tasks have very different cost per task profiles. Tracking the correction rate on AI-generated code captures the human cost that sits alongside the token cost.
Is the frontier model always the better choice for cost per task?
No. On simple, high-volume work such as autocompletion and small well-scoped edits, a cheaper model usually finishes in one attempt, so its low token rate carries straight through to a low cost per task. The frontier model tends to win on hard tasks where failed attempts and review overhead dominate. The efficient setup for most teams is routing by task type rather than standardizing on a single model.
What is cost-aware routing and how does it relate to cost per task?
Cost-aware routing sends each request to the model that is cheapest per finished task for that class of work: lighter models for routine tasks, frontier models for complex ones. It depends on measuring cost per task per model, because routing decisions made on token price alone will send hard tasks to cheap models that then cost more to finish. Measured in cost per task, the routing rules become clear.
Recommended
Leads commercial and go-to-market. Founder of Emberwood, an AI-driven cold-email agency for B2B, with a background in outbound, lead generation, and sales.
