AI cost: 33% cheaper tokens, same cost per task?

The token price fell 33% and cost per task stayed at US$ 1.98. For whoever decides the model route, the new rate does not change the bill on its own: the number that survives the decision is the cost of the task that comes out done.
The AI cost spreadsheet of a company that already runs models in production and receives the invoice in dollars has two columns that disagree. In one sits the price per million tokens, 33% lower since 23 October 2026. In the other sits cost per task, which did not move. The budget meeting picks which of the two goes on the slide, and the easier one to explain almost always wins. The slide is wrong when it shows one column and answers for the other.
Price per token is a number the supplier publishes and finance recognizes. Cost per task forces a definition of what counts as a completed task, and nobody wants that discussion on a Tuesday.
The rate does not decide.
A model can become 33% cheaper per token and keep costing the same per task. Whoever decides by the rate buys a discount and pays for rework.
What changed in the model and what did not change in the bill
Kimi K3.1 Pro arrived on 23 October 2026 with a first-party price 33% lower across the three rates, Intelligence Index 55 and an index cost per task of US$ 1.98, practically the same as Kimi K3. Whoever reports AI cost chooses between the two figures.
The published numbers are below, without recalculation.
| Metric | Kimi K3 (previous) | Kimi K3.1 Pro |
|---|---|---|
| Intelligence Index | 44 | 55 |
| Index cost per task | not published as a number; described as practically equal to the new one | US$ 1.98 |
| Input price, per million tokens | not published in the material read | US$ 2.00 |
| Output price, per million tokens | not published in the material read | US$ 10.00 |
| Terminal-Bench 4.0 | 13% | 67% |
The three cells without a number are deliberate: the source publishes the 33% cut and the new price, not the previous rate in dollars, and leaves the previous model's cost per task without a figure.
The model entered 4th place in the Intelligence Index, 11 points above the 44 of the previous one and behind three models, among them the leader, at 58.
The combination only looks strange to whoever treats price and cost as synonyms. A 33% cut in the table is a cut in the rate. The rate does not determine cost per task on its own: consumption, cache and reasoning also weigh, and each set of tasks combines the three in a different way. How much of the discount survives is a qualitative reading.
Price per token and cost per task measure different things
Price per token is the rate: what the provider charges per million input, output and cache tokens. Cost per task is the bill: the spend divided by the tasks of the index. The first is read in the supplier's table. The second depends on consumption, on the hit rate and on what counts as a completed task.
The rate is not the bill.
The composition of the number is published: input, cache hit, cache write, reasoning and response, divided by the number of tasks and weighted by the weight of each evaluation in the index. The method is the same one the piece on cost per task deciding the route uses to break ties between models: the arithmetic is of cost, and not of rate. With it, the evaluator publishes US$ 1.98 in the launch article and US$ 2.11 on the model page, as a weighted average. The difference between the two figures is one of method.
| Criterion | Price per token | Index cost per task | Cost per task on your load |
|---|---|---|---|
| Unit | US$ per million tokens | US$ per index task | US$ per accepted task |
| What it measures | the rate charged | the average spend on the tasks of the index | the spend of your own operation |
| What it ignores | consumption and rework | the acceptance criterion of your load | the third-party benchmark |
| When it misleads | when consumption grows | when the load differs from the index one | when nobody measures per call |
| How it is measured | the provider's table | the evaluator's method | the record of each call |
Why 33% less on the token did not become 33% less on the task
The price of the LLM token fell 33% and consumption per task rose. The model spends 55 thousand output tokens per index task, against 48 thousand for the previous one, 14% more. Longer reasoning buys accuracy and charges tokens. The source calls cost per task practically equal and does not claim that the arithmetic closes.
Three mechanisms explain the mismatch. The first is that reasoning tokens enter the output bill: a model that thinks more before answering charges for that thinking on the same line as the response.
The second is the cache. The cache hit at US$ 0.20 per million reduces the cost of repeated context, with a 90% discount on that rate. A repeated system prompt benefits; a new input on every call does not.
The third is verbosity. The new model generated 150 million output tokens across the whole index, against a class median of 87 million, according to the model page read on 26 October 2026. It writes more in order to get more right.
The 33% and the 14% are published facts, and the equality of cost per task is a description from the source, not a result that can be rebuilt from the two percentages. The three figures do not close an exact account, and any number that closed the gap would be invented.
From 13% to 67% on Terminal-Bench: the cost of the task that comes out done
On Terminal-Bench 4.0, the previous model solved 13% of the tasks, and failed 87% of the time. Kimi K3.1 Pro solves 67%, the highest score the evaluator measured. A terminal task that fails does not cost the price of one attempt: it costs the attempt, the repetition and someone's time checking the result.
Call cost per completed task whatever the operation pays: the total spend divided by the tasks that passed the acceptance criterion. The difference from the index cost per task is in the denominator. An agent that runs several times and delivers few accepted tasks divided the spend by a small number.
The agentic axis moved in more than one measurement. In GDPval-AA the new model scores 1,846 Elo, third place, 312 above the previous one, behind two models at 1,866 and 1,857. In AutomationBench-AA, the rate goes from 58% to 73%.
The precision that separates reading from error: cost per task is measured on the tasks of the Intelligence Index, and Terminal-Bench 4.0 is another set. The two figures do not form a joint account, and multiplying one by the other would produce a number that no source publishes. At 67%, 33 out of every 100 terminal tasks remain unsolved, and each of them consumed token, time and a human check.
The bill is the accepted task's. Not the attempt's.
The leader of the index is not the leader of the agentic task
The leader of the Intelligence Index is Claude Opus 5.5, at 58. The leader of Terminal-Bench 4.0 is Kimi K3.1 Pro, at 67%, ahead of Claude Sonnet 5.5, at 64%. These are two scoreboards and two questions, and a router that consults only the index can choose the wrong model for the load Terminal-Bench measures.
The index, in version 4.3.2 read on 26 October 2026, is a composite of ten evaluations, among them AA-Briefcase, GDPval-AA, AutomationBench-AA and Terminal-Bench 4.0. Each enters with a weight defined by the evaluator's method, and the result is an average that rewards balance. A model that is good at everything rises; one that is excellent at one thing and mediocre at the others does not.
Terminal-Bench measures one thing only: whether the agent finishes the terminal task. It does not measure writing, it does not measure extraction, it does not measure conversation.
The two scoreboards coexist without contradicting each other. The index leader's score on Terminal-Bench is not in the source read and does not appear here. What the source publishes is the highest score in the set, 67%.
How to decide the route with the two metrics
The decision has four steps: define what counts as a completed task, measure cost per task on your own load, compare with the published figure and revise the rule when the table or the index changes. The result is a routing rule by task type, not a ranking of models.
The definition comes before the purchase. Does a reopened support ticket count as completed?
- Write the acceptance criterion per task type, before comparing price.
- Measure the spend per call with model, tokens and result in the same record.
Without that, cost per task on your own load is the month's invoice divided by a number nobody counted.
- Compare the measured cost with the published one, treating the difference as information.
- Revise the rule when the table or the index changes version, as the real cost beyond the price per token shows.
The AI cost that reaches finance is only auditable when each call carries model, tokens and result. The LLM router of Nexforce Router is a gateway with routing across more than 300 models, an OpenAI-compatible API, a ranking by price and performance updated continuously, budget per key and per project with a spend cap, fallback and failover between providers, response and embedding cache, and a complete trace of each call.
The limit: the layer measures and governs the decision, it does not decide what counts as a completed task, and no tool decides that in the buyer's place.
Still missing is the layer between the dollar rate and the cash in reais. Nexforce's internal estimate is that import charges and currency conversion raise the effective cost of the token by up to 55%, and a bill of US$ 100,000 arrives at US$ 100,000 plus up to 55% in outlay. At the ceiling, it leaves as US$ 155,000 paid out.
When the token price is still the right criterion
The price per token still decides when the output is short, the volume is high and the accuracy is rarely questioned: classification, field extraction, label translation, form answer. In those cases the LLM cost per token converges to the cost per task, and the simplest metric is the most honest one.
First condition: short output. When the answer fits in a few lines and the format is fixed, consumption varies little, and the output rate decides the bill again.
Second: high volume with repetition. A pipeline that processes the same input all day has a predictable cache, and the 90% discount becomes a component.
Third: an error that is cheap to correct. Classifying a ticket into the wrong queue costs little; drafting a contract with an invented clause does not.
The model router benchmark enters as support, not as a verdict: it teaches how to read a composite index without confusing average with performance.
Conditional verdict: for short output, high volume and a cheap error, the price per token decides; for a load in which the task has to come out done, the cost per completed task decides.
Frequently asked questions
What is cost per task in a language model? It is the spend divided by the tasks of the index, not the list price per million tokens. The evaluator adds input, cache hit, cache write, reasoning and response, divides by the number of tasks in the index and weights each evaluation by its weight in index v4.3.2, which produces an average in dollars per task.
Why did the token price fall 33% and cost per task stay the same? Because consumption per task rose with the cut. The new model uses 55 thousand output tokens per index task, against 48 thousand for the previous one, and reasoning is charged on the same line as output. The source calls the account practically equal, at US$ 1.98.
Does the published cost per task serve my load? It serves as a reference, not as a budget. The published number is measured on the tasks of the Intelligence Index, and your load does not reproduce that mix. Cost per completed task depends on the acceptance criterion, on the hit rate and on consumption per call, and it only appears when each call is recorded with model and tokens.
How does an LLM router use the two metrics in practice? It can apply a rule per task type, sending short output to the model with the lowest rate and the agentic load to the one with the best hit rate, and measuring both. What it does not do on its own is decide what counts as a completed task. No router decides that.
Does the new model already have open weights? No. The source says the weights were not published and projects that, once they are, the model will be the open one with the highest score, with the gap between the open and the proprietary leader falling from 12 to 3 points. What is published is the architecture: a 1M-token window, 2.8 trillion total parameters and 104 billion active.
References and Further Reading
- Artificial Analysis, launch article, 23 October 2026: https://artificialanalysis.ai/articles/kimi-k3-1-pro-launch-benchmarks (accessed on 26/10/2026).
- Artificial Analysis, model page, with cost per task as a weighted average and the composition of the Intelligence Index: https://artificialanalysis.ai/models/kimi-k3-1-pro (accessed on 26/10/2026).
What to do with this bill
The bill that decides is not the one in the supplier's table. It is the one that divides the spend by the tasks the operation accepted, with an acceptance criterion written before the price comparison, because a number born from the rate and not from acceptance does not survive the first meeting in which someone asks how many tasks came back unsolved. The criterion comes first. The rate changes without warning the budget.

Save up to 50% in creditswith a single smart API
Connect your operations to our AI Router and optimize the consumption of multiple LLMs
Free TrialRelated articles

LLM gateway: why does latency grow with context?
A benchmark published on 3 October 2026 by an open-source LLM gateway project measures 553 ms of TTFB in a 439,945-token conversation and 35 ms after the gateway started skipping three pre-flight steps, among them the count of the entire context before calling the model. What that changes in the latency budget of anyone operating agentic load.
Read more
AI Model Router Benchmark: Complete Metrics Guide
Comprehensive guide to evaluating AI model router benchmarks: workload-specific metrics, statistical breakdown of composite indexes, and how weight sensitivity flips rankings.
Read more
Live Web Search Benchmark for AI Agents: Practical Guide
See how search engine, depth, and LLM interact in agent workflows. Learn why public benchmarks fail and how to measure live production tasks.
Read more