Late July, Moonshot published the full weights for Kimi K3, free to anyone with the hardware to run them. Three days later OpenAI cut GPT-5.6 Luna by 80 percent, on a model it had shipped twenty-one days earlier.
But cheaper tokens don’t necessarily mean a cheaper finished job. The inference cost of a task is the price per token multiplied by the number of tokens the system uses to finish it. That token count can vary dramatically with the software around the model: context management, tool use, retries, and the way the harness decomposes the work. Today engineering teams are directing agents at longer tasks and packing more context into every call. The value is shifting to making those longer tasks useful.
A finished task can carry costs across inference, orchestration, tools, runtime, and evaluation. Inference has the cleanest standardized price: providers publish rates per token, while the rest is usually bundled, metered differently, or left to the buyer to absorb. I wanted to explore what happens as that price keeps falling, where the remaining costs go, and which companies are positioned to capture the margin.
This piece explores the following:
Is the token a poor unit for pricing AI?
Orchestration can matter more than model choice
Scoring is still an open problem
What happens if orchestration commoditizes, and what is left when it does
The token and metering
When Edison opened Pearl Street Station in September 1882, electricity was still awkward to meter. Edison initially charged per lamp, then introduced an electrolytic meter that estimated consumption by measuring how much zinc moved between plates. The meter worked, but workers had to remove and weigh the plates. Metering became easier as practical mechanical meters arrived later in the decade.
In 1888, Westinghouse engineer Oliver Shallenberger noticed a spring rotating in the magnetic field of an AC arc lamp. Within weeks he built a practical AC ampere-hour meter, and Westinghouse sold more than 120,000 over the next decade. Watt-hour meters that measured energy directly also appeared around this period and later became the standard basis for utility billing.
The important shift was not the invention of metered billing, which already existed. Electricity consumption became increasingly practical to measure and standardize across customers, allowing utilities to price the underlying resource rather than bundle it into an entire lighting service.
You care about outcomes: a resolved ticket, merged pull request, approved design, correct answer. But you pay for tokens, which are easy to measure and only loosely tied to those outcomes. Ten thousand might solve the task, disappear into retries, or sit unused in context.
The difference is the surrounding system: context, tools, retries, runtime, and evaluation. Since outcomes cannot be metered consistently, the industry prices a convenient proxy for consumption, tokens.
Orchestration can (does!) matter more than the token
Late July made the point literally. Anyone with the hardware could download K3 without paying a license fee for the weights, although running it still required substantial compute. But the cost of a finished task can still vary by multiples, depending on the system built around the model.
Four days after the Luna cut, Composio put the same Kimi K3 model inside eight different agent harnesses, the software that decides what to send the model, how many times, and which tools it can reach, then gave each one the same tasks. The only meaningful change was the software around the model. Pass rates ran from 68 to 88 percent, and the cost of a completed task varied by more than 4x. Composio sells tooling into this market, so treat the benchmark accordingly, but the result is hard to miss: the harness changed both what the model could finish and what each finished job cost.
A July arxiv paper tested the same idea more carefully. The researchers kept the models and tasks fixed and changed the orchestration; better orchestration cut the cost of completing the same work by about 40 percent. And Databricks found a similar result on coding agents: the same model could cost more than twice as much depending on the harness around it.
Companies running agents at scale already think in these terms. DoorDash says its internal agent platform handled 130,000 engineering tasks in one month, and reports the work in tasks, code reviews, and workflow runs. Those units describe the work the company wanted done. Tokens count model activity along the way, not the compute consumed or the work completed.
The harness can change over time too. Prime Intellect’s open-source Prime Agent can update its own prompts, memory, skills, and sub-agents based on previous runs. Exo, Martin Casado’s open-source harness, is recursive by design: the agent can rewrite its own prompts, memory, tools and the harness code it runs on, then rewind if an experiment goes badly. So the software determining the cost of a task is not fixed.
How much context to hold and how many retries to allow are harness decisions, and they land on memory. Long-running agent sessions put heavy pressure on the key-value cache because each model call can reuse a growing conversation prefix. If the required cache blocks are unavailable, the serving system may reload them from another memory tier or recompute them, adding latency and cost. NVIDIA now treats cache-aware routing, eviction, and storage across GPU memory, host memory, and disk as core optimizations for agentic inference.
The cost of serving those tokens therefore reflects the work requested, the behavior of the harness, and the efficiency of the serving system, while the token count itself mostly reflects the first two.
That creates the next problem: before anyone can price agent work cleanly, someone has to define what counts as a finished job.
Scoring is still an open problem
Pricing a finished job means knowing the job finished, and that scoring problem is unsolved rather than unsolvable. A harness will check whatever somebody wrote a check for. Coding is unusually amenable to outcome-based scoring because many tasks come with tests or other machine-checkable signals that the harness can run before handing work back. Much of production work lacks an equivalent test.
Reinforcement learning has a related problem on the training side. It runs a task many times and needs a reward signal for each attempt, so some way to score or compare outcomes has to exist during training. In a new domain, building that signal can require the same expertise that made the work expensive to automate. Where no reliable automatic scorer exists, teams fall back on human review, model-based graders, proxy metrics, downstream business metrics, or some combination of them.
So vendors bill for what they can count instead. Three different approaches I’m seeing:
Cognition charges for compute consumed, through a unit it invented called an Agent Compute Unit. Task complexity, how specific your prompt was, context size, how many files were touched, runtime and how much back and forth it took all feed into one number. Some of that is the work you handed over and the rest is the agent thinking about it, so the more it flails the more you owe. The rate per unit sits in each order form, so two buyers can’t compare what they paid.
Fin charges $0.99 per outcome, which is the closest anyone comes to billing the finished job. A resolution counts when the customer confirms the answer worked, or when the customer goes quiet for 24 hours after Fin’s last reply. The first half of that definition is a real outcome and the second half is an assumption.
Salesforce started at $2 a conversation, then moved to roughly ten cents per action. An action is one thing the agent does, like retrieving a record or updating one. Smaller, easier to count, and further from the outcome than the conversation it replaced.
These meters have something in common: Cognition’s runs on compute consumed, Salesforce counts the actions taken, and Fin can infer a resolution after 24 hours of silence. A customer who abandons the conversation can initially look the same as one whose problem was solved, although Fin says the charge is reversed if the customer later returns to the same issue. Each vendor has found a countable proxy for work that is easier to bill than correctness itself.
Will the harness commoditize too?
There is a strong case that orchestration commoditizes the way models have begun to. I think it’s about half right.. because orchestration is software, and software standardizes.
Anthropic released MCP in 2024, and it became the common way for a harness to call a tool inside about eighteen months. OpenAI now calls it an industry standard. DeepSeek ships an open-source agent harness, and Anthropic’s Agent Skills format became an open standard that Codex uses too. DoorDash built Flux internally because it wanted control over permissions, integrations, sandboxes, and company-specific context. In other words, we can increasingly assemble the common pieces ourselves.
But any deployment still accumulates assets that aren’t being captured in a standardized way. These include the evals and reward functions used to score work, plus production traces, corrections, private workflow data, and trained checkpoints. Because two companies can start with the same model and harness and own very different systems six months later, neither token pricing nor a harness license puts a value on that difference.
Today, there is no settled answer on where accumulated agent improvements live or how portable they are. Anthropic’s Managed Agents can run tool execution and files either in Anthropic-managed sandboxes or in customer-controlled self-hosted sandboxes, although Anthropic says memory is not currently supported in the self-hosted mode. Prime Intellect’s Prime Agent writes memory, skills and sub-agent changes to disk, where the customer can retain them. Harness-R1 takes another approach: it freezes the target model and trains a separate 9B harness engineer to generate executable runtime patches from failed runs. In that setup, the improvement lives in the harness engineer and the patches it produces rather than in the target model’s weights. These architectures put accumulated improvement in different places, so portability depends on which artifacts a system creates and which of those artifacts the customer can keep.
A few companies sell that improvement loop as the product:
Applied Compute sells the whole loop, training and evals and inference and production traces, and tells customers the resulting model is theirs
Prime Intellect packages tasks, a harness and a scoring rubric into environments customers train and evaluate against
River AI raised $1.1 billion on letting companies train, deploy and own customized open-weight models
Where the value went
Soon after Kimi K3 was published, multiple vendors were serving the same weights, making price one of the easiest dimensions to compare across providers. Open weights made the model itself easy to substitute, so much of the value shifted into the parts a download cannot reproduce: the harness that helps an agent complete a task, the evals that determine whether the task was completed correctly, and the accumulated record of corrections, failures, and successful approaches inside a company. Two companies can run identical model weights and still have very different systems around them, and that difference compounds as those systems keep learning.
That helps explain why token pricing is so visible while the rest of the stack is hard to price. K3 inference can be compared across providers down to fractions of a cent, which is exactly what happens when a product becomes commoditized. Buyers negotiate aggressively over token rates because those rates are easy to see, even though model costs are already falling quickly on their own. The harder question is the value of a completed job. A meaningful price per finished task becomes possible once companies can score outcomes cheaply and reliably enough to bill against them. The providers that can measure their own work best will likely be the first to price that way.
Open weights were also supposed to reduce lock-in. At the model layer, they do. A company can leave a provider and take the model with it. What may stay behind is six months of agent corrections, custom evals, execution traces, and learned knowledge about which approaches fail in a particular codebase. That creates a new kind of switching cost at the system layer, even though few contracts put a number on it. Token prices keep falling and remain easy to negotiate. The more important term may be what a customer can take with them when they leave: the evals, traces, corrections, and operational knowledge that make the agent valuable in the first place.
What I expect
The electricity industry never really defined light. What it did was standardize the input it could measure, added a charge for capacity, and left it to the customer to turn that energy into light efficiently or waste it. That capacity charge arrived in 1892, once utilities worked out that a factory drawing hard for two hours forced more generating plant than a shop drawing steadily all day.
Agent pricing may settle on something similar: a capacity or commitment charge plus usage, rather than one clean price for a finished job.
By late 2026 or early 2027, I expect at least one large enterprise procurement to require cost per resolved task alongside token pricing. Independent evaluation should also become a normal part of buying agent systems, because otherwise the vendor defines both the product and whether the product worked. And at least a handful of companies selling fixed-price outcomes will probably add a consumption component after task variance starts moving gross margin.
If enterprises are still choosing providers mainly on price per million tokens two years from now, this argument was wrong and commoditization reached further than I expect.
For anyone signing a contract now, read the unit on the invoice. Token pricing leaves more of the variance in task length, retries, and tool use with the buyer. A fixed price per finished job moves more of that variance onto the vendor.