The short answer: Cost per task is the number you get when you stop comparing price per million tokens and start comparing what one completed unit of work actually costs. It is the most useful single figure in model selection, because token price tells you nothing about how many tokens a model burns to finish the job, and the spread is enormous: on Artificial Analysis's Coding Agent Index, models three to four index points apart differ by ten to sixty times in cost per task.
It is also frequently misread. The number is an average over a specific benchmark's task mix, and your task mix is not that one.
The metric has become the default way serious teams compare models, and the reason is simple arithmetic. A model at half the token price that needs three times the tokens to complete the same task is not cheaper. Price per million tokens is an input cost. Cost per task is an outcome cost, and outcomes are what you are actually buying.
How the number is built
Conceptually it is straightforward. Run a model against a fixed set of tasks under a fixed harness. For each task, record every token the model consumed, including the ones you do not see: reasoning traces, retries, tool call round trips, and the context that gets resent on each turn of an agent loop. Price those tokens at the model's published rates. Divide total cost by the number of tasks.
The three things that make the result surprising are all in that middle step.
- Reasoning tokens count. On models that think before answering, those tokens are generated and billed even though the user never reads them. A model with a low output price and a long reasoning habit can cost more per task than an expensive model that answers directly.
- Agent loops resend context. In a multi-turn agent, the conversation so far is input on every turn. Task cost grows faster than linearly with the number of turns, which is why an agent that needs eight tool calls is not twice the cost of one needing four.
- Failures are still billed. A model that fails a task and retries consumed real tokens. Whether the benchmark counts that attempt materially changes the number.
Why the spread is so wide
The figures that make the point best come from the Coding Agent Index. Cursor's Composer 2.5 sits third at index 62 for roughly $0.07 per task on its standard tier. The two models above it, Claude Opus 4.7 at index 66 and GPT-5.5 at index 65, cost $4.10 and $4.82 per task.
Three to four index points. Roughly ten to sixty times the cost. We worked through what that means for model selection in the workhorse models analysis, and the conclusion holds: for most of the work most teams do, the frontier model is not buying you what the price difference implies.
| What you compare | What it tells you | What it hides |
|---|---|---|
| Price per million tokens | Input cost of the raw material | How many tokens the job needs |
| Benchmark score | Capability ceiling on that benchmark | What that capability costs to use |
| Cost per task | What one completed job costs | Whether their task mix matches yours |
Where people misread it
The metric is good. The mistakes are in applying it.
- Treating an average as your number. A published cost per task is an average across that benchmark's distribution of tasks. If your workload is mostly short, well-specified edits, your real cost per task will be far below the published figure. If it is mostly sprawling multi-file refactors, far above. The ranking usually transfers; the absolute number usually does not.
- Ignoring the harness. Cost per task measures a model inside a scaffold. Change the scaffold, by adding caching, trimming context, or capping tool call depth, and the number moves without the model changing at all. That cuts both ways: it means your own engineering can move your cost per task substantially.
- Forgetting caching. Prompt caching changes the arithmetic significantly for repeated context, and cache reads and writes price differently from ordinary tokens. A benchmark that does not use caching will overstate the cost of a workload that does. We covered the accounting trap in prompt caching breaks cost tracking.
- Assuming it is stable. Providers change prices, retire models and adjust reasoning behaviour. A cost per task figure has a shelf life measured in weeks, which is exactly why hardcoding pricing tables in your own code goes wrong, as we argued in the stale pricing table problem.
Measuring your own
The published figure is for shortlisting. The number that should drive your decisions is the one from your own traffic, and getting it requires only that you record the right things per task rather than per request.
For each completed unit of work, capture: a task identifier that survives across the whole agent loop, the model used, input tokens, output tokens, reasoning tokens separately if the provider reports them, cache reads and writes separately, the number of turns, and whether the task succeeded. Aggregate cost by task identifier rather than by request and you have your real cost per task, including the failures, which the vendor's number may not include.
That attribution is harder than it sounds in an agent architecture, because a single task fans out across sub-agents and tool calls that each look like independent requests. We went through the attribution problem in token cost attribution across agents and subagents.
The honest take
Cost per task is the right metric and it deserves the attention it now gets. Use published figures to shortlist, because the ordering they produce is usually sound and the ten-to-sixty-times spreads are real signal, not noise.
Then measure your own, because the absolute number is a property of your task mix and your harness, not of the model. Teams that skip that second step end up making a good decision with someone else's data, which works until their workload stops resembling the benchmark. That usually happens quietly, and the first sign is a bill that does not match the model you thought you chose.