The Run-Cost Era: Why Agents Cost More to Run Than to Build

There is a number that agent vendors love to quote and a number they would rather you did not think about. The number they quote is the build cost: what it takes to stand up an agent, wire it to your systems, and ship it to production. The number they avoid is the run cost: what it takes to keep that agent running, every day, for the life of the thing. For the first fifteen years of the cloud era those two numbers lived in a comfortable ratio — you paid to build software once and you paid a modest, predictable amount to run it forever. Agents break that ratio. They break it because an agent is not a piece of software that answers a request; it is a process that runs, sometimes for minutes, sometimes for hours, occasionally for days, and every hour it runs it burns tokens at a rate that a chatbot never approached.

This is the shift the industry is only now pricing correctly. The build got cheap — genuinely, dramatically cheap — while everyone was watching. A competent multi-agent system that would have been a six-month engineering project in 2024 is now a two-to-three-week build quoted in the low tens of thousands of dollars. But the run cost went the other direction, and it went there quietly, because it does not show up in a demo and it does not show up in a proof of concept. It shows up in month four, in the cloud bill, in the line item nobody modeled. The story of enterprise AI in the back half of 2026 is the story of that line item finally getting large enough to reprice the entire market around it.

The build got cheap while nobody was modeling the run

Start with the build, because the build is the part everyone can see. In July 2026 the development studio Digital Applied published a cost index for AI agents that put concrete numbers on something practitioners had been feeling for a year. A simple task agent — the kind that classifies a ticket, drafts a reply, or looks something up — costs roughly 5,400 to 9,000 dollars to build. A retrieval-augmented workflow agent, one that reasons over your documents and takes multi-step actions, runs 13,500 to 22,500 dollars. A full multi-agent system, with a planner coordinating specialized sub-agents, lands at 27,000 to 45,000 dollars. The index derives these from engineering days at a blended rate, which is exactly how an agency would quote them, so treat them as a competent market estimate rather than a law of physics. But the shape is right, and the shape is the point: building an agent is now a routine, bounded, quotable piece of work.

That number keeps falling. Every improvement in tool-calling reliability, every better framework, every model that can hold a longer plan in its head without losing the thread makes the build cheaper. The build cost is on the same curve as every other kind of software: down and to the right, commoditizing toward the cost of the labor to specify what you want. If the story ended here, agents would be the cheapest enterprise software ever made.

The story does not end here, because the same index quietly published the other half of the ledger — the monthly run cost — and the two halves do not behave alike.

The bars tell the whole story before a single word of analysis. A simple task agent is roughly break-even in year one: cheap to build, cheap to run. But climb the complexity ladder and the run bar pulls away from the build bar fast. A retrieval workflow agent, modeled at around 2,700 dollars a month, spends more running in its first year than it cost to build. A multi-agent system, at roughly 6,250 dollars a month, runs up 75,000 dollars in twelve months against a 36,000-dollar median build. And here is the part that should reorganize how you think about the whole category: the build happens once. The run happens every month, forever, and it grows as usage grows. Year two is another 75,000 dollars. Year three, more, because you added agents and they got busier. The build is a point. The run is a slope.

This is why the framing of "how much does it cost to build an agent" is the wrong question, asked out of habit from the era when building was the expensive part. The right question is the one every FinOps team is now learning to ask: what does it cost to run this thing at the scale I actually intend to use it, and does that number still make sense when the agent is doing its job well enough that everyone wants more of it? Success, for an agent, is the thing that makes the bill frightening.

Why running an agent costs what it costs

To understand why the run cost behaves so differently from ordinary cloud compute, you have to understand what an agent actually does when it runs, and how different that is from what a chatbot does when it answers.

A chatbot answers a question. You send it a prompt, it sends back a completion, the transaction is over. The token cost is the prompt plus the response, once. An agent does not answer; it works. It receives a goal, makes a plan, takes a step, observes the result, revises the plan, takes another step, and repeats until it decides it is done. Each of those steps is a full model call. And here is the mechanism that makes the economics diverge: at every step, the agent resends its accumulated context — the original goal, the plan, every prior observation, every tool result — so the model can reason about what to do next. The context does not reset between steps. It grows. Step twenty carries the weight of steps one through nineteen.

Gartner put a multiplier on this in March 2026: an agentic task consumes roughly 5 to 30 times the tokens of a comparable single chatbot request. That range is wide because it depends entirely on how many steps the task takes, and the number of steps is exactly what you cannot control from the outside — it is a property of how hard the task turns out to be, discovered only by attempting it. An agent that resolves a query in three steps is cheap. The same agent, handed a query it cannot crack cleanly, might grind through forty steps, resending an ever-larger context each time, and cost you an order of magnitude more for a task that looks identical from the outside.

The scaling is worse than linear because of that growing context. Directional figures from operations tooling vendors put the token consumption of a five-step loop at roughly three times a single call, a fifty-step loop at more than thirty times, and a two-hundred-step autonomous session — think an agent debugging its way through a codebase — at more than a hundred times a single request. These are estimates, not audited measurements, and you should hold them as such. But the curve they describe is real and it is mechanical: cost per task rises faster than the number of steps, because every step drags the accumulated history along with it.

Now layer on the second thing that happened in 2026: agents started running for much longer. The research group METR tracks the length of tasks that frontier models can complete autonomously, and their central finding is that this horizon is doubling roughly every four to seven months. Tasks that took minutes of autonomous work in 2024 stretched toward hours by mid-2026. A longer horizon is not a neutral capability improvement. It is, mechanically, more steps, more resent context, more tokens per dispatch. The very thing that makes agents more useful — their ability to stay on a hard task without a human babysitting each step — is the same thing that makes each dispatch more expensive. Capability and run cost are not in tension. They are the same axis, read from two directions.

There is a genuine tension in the token math worth naming, because it is the thing that fools people. Token prices are falling — the blended enterprise cost of a million tokens drifted toward the low single digits of dollars through early 2026, and every model generation pushes it lower. So the intuitive conclusion is that inference is getting cheaper and run costs should be shrinking. They are not, and the reason is a scissors: the price per token falls, but the number of tokens per task rises faster, because tasks are getting longer and carrying more context. You are paying less for each unit and consuming dramatically more units, and the product of those two curves points up. I described a version of this scissors from the vendor side in my analysis of the AI token pricing trap; the run-cost era is the same mechanism experienced from the buyer's side of the invoice.

The bill that is not made of tokens

Here is where the honest version of this argument has to slow down and correct its own oversimplification, because "run cost equals inference cost" is a seductive story and it is not quite true.

When Digital Applied broke down that monthly run figure, the largest single line was not tokens. It was human oversight. The recurring cost of an agent in production is inference plus the vector database plus monitoring and observability plus the human hours spent reviewing what the agent did, catching its mistakes, tuning its prompts, and handling the cases it escalated. And in their model, that last category — the senior person whose job is now partly to supervise a fleet of agents — is the biggest recurring number of all.

This complicates the clean thesis in a way that actually strengthens the deeper one. If your model of agent economics is "cheap once inference gets cheaper," you are going to be wrong twice: wrong because inference cost per task is rising even as price per token falls, and wrong again because a big chunk of the run cost was never inference to begin with. The recurring cost of an autonomous system is the cost of trusting it, and trust is expensive. You pay for the tokens the agent spends thinking, and you pay for the humans who make it safe to let it think unsupervised. Both are run costs. Both recur. Neither shows up in the build quote.

This is the part that connects the run-cost era to something I have been circling for months: the quiet death of seat-based pricing. When I wrote about the end of the seat in agentic coding, the argument was that a per-user subscription cannot survive contact with a product where one user can dispatch a task that consumes a thousand dollars of compute over a weekend. The run-cost era is the general case of that specific observation. Seat pricing assumes cost scales with people. Agent cost scales with work dispatched, and a single person can dispatch an unbounded amount of work. The two models are not compatible, and the market is now living through the adjustment.

Both old pricing models break, in opposite ways

The reason this matters beyond a FinOps spreadsheet is that it breaks the two dominant ways of paying for software, and it breaks them in opposite and instructive directions.

The resolution the market is groping toward is neither pure seat nor pure token. It is the task, or the run, or the outcome — a priced unit that sits above the token and gives the buyer something forecastable while letting the vendor pass through the variance in aggregate. You can already see the shape of it: run budgets that cap what a single dispatch may consume, task-based pricing that charges per completed job rather than per token, tiered "agent-hour" allowances that let a buyer reason about capacity the way they reason about cloud instances. I laid out the broader version of this repricing in the efficiency turn, and the run-cost era is what forces the issue: you cannot sell a task that spans billions of tokens using a price sheet designed for a single completion.

I think the endpoint is close enough to predict with a straight face, which is why I am attaching a dated claim to it: my prediction that run-based agent billing becomes a standard SKU by the end of 2027. The token will not disappear as a unit of cost accounting, the way the CPU cycle did not disappear. But it will disappear as the thing enterprises are quoted and billed on, replaced by a unit that maps to a job rather than a computation.

The money already moved

If you want to know where a market is going, watch where the capital is being committed, because the capital has to make a multi-year bet and it cannot afford to be sentimental. And the capital in mid-2026 made a very specific bet: that the binding constraint on agents is not capability but run cost, and that whoever makes long-horizon agents cheaper to operate captures the category.

Read that sequence as one argument and it is unmistakable. Sail Research is the purest expression: a company whose only reason to exist is that long-horizon agents are too expensive to run, and whose pitch is a claimed order-of-magnitude reduction in inference cost for exactly the hours-or-days workloads that break every existing price model. Sequoia and Kleiner Perkins do not write an 80-million-dollar check on a seed-and-Series-A because agents are hard to build. They write it because agents are expensive to run and someone has to fix that, and the someone who fixes it owns a toll booth on every autonomous task the industry dispatches.

And then Moonshot's Kimi K3, at the end of that timeline, is the run-cost wall made literally visible. Here is the most capable open model in its class, topping the coding leaderboards, and the company cannot sell it to new users because it cannot afford to run it at the demand its capability created. The model is not gated by quality. It is gated by the cost of serving it. That is the run-cost era in a single event: the frontier is now defined not by what a model can do but by what it costs to let a model do it, at scale, for everyone who wants it. I wrote about the supply-side version of this dynamic in the compute allocation turn, and Kimi K3 is what it looks like when a single company hits the wall at the moment of its greatest success.

A worked example: the task that ran all weekend

Abstractions are easy to nod along to and easy to forget, so make it concrete. Picture a mid-sized company that ships a support-automation agent — a retrieval-augmented workflow agent, squarely in that 13,500-to-22,500-dollar build tier. It went to production in the spring. The demo was flawless, the proof of concept came in at a few hundred dollars of API spend, and the build invoice was paid and forgotten. For the first month it handled a few thousand tickets, cost a couple thousand dollars to run, and everyone was delighted. The build had been cheap and the run looked cheap too. This is the trap, and it springs in month three.

In month three, two things happen at once, and they are the same two things that happen to every successful agent. First, the agent works well enough that the company routes more to it — not just the easy tickets it was scoped for, but the messy ones, the multi-part ones, the ones a human used to escalate. Those are the tickets that take the agent not three steps but thirty, resending a swelling context at each one. Second, someone connects the agent to a few more tools, so now it can act as well as answer, which means more steps still. The per-ticket cost did not change on the price sheet. The per-ticket consumption tripled, because the mix of work shifted toward the hard tail, and the hard tail is where the step count — and therefore the token bill — lives.

Then comes the Friday. A batch job hands the agent a genuinely difficult, open-ended task — reconcile a quarter of ambiguous cases, say — and the agent does exactly what it was built to do: it stays on the problem. It plans, it acts, it observes, it revises, and it keeps going, because nobody set a step budget and the task is genuinely hard. It runs through Friday night. It runs through Saturday. By the time someone looks on Monday, a single dispatched task has executed for the better part of a weekend, resending an ever-growing context across hundreds of steps, and it has quietly spent more than the agent cost to build. The agent did not malfunction. It did precisely what autonomy means. The malfunction was in the budget, which modeled the build and never modeled the run.

None of the numbers in that story are exotic. A two-hundred-step autonomous session at roughly a hundred times the token consumption of a single call, run against a task the agent could not cleanly close, is not an edge case — it is the predictable behavior of a capable agent handed a hard problem with no ceiling on how long it may work. And the fix is not a better model or a cheaper token. It is the operating discipline that most teams are still learning, because they are still budgeting agents with instincts inherited from an era when the build was the expensive part.

What this means if you are actually shipping agents

Strip out the market commentary and there is a concrete operating discipline buried in all this, and it is worth stating plainly because most teams are still budgeting agents as if they were ordinary software.

First, budget the run, not the build. The build quote is the cheapest and least informative number in the whole engagement. Before you approve an agent, model what it costs to run at the volume you actually intend — not the demo volume, the real volume, the volume that exists when the agent works well enough that everyone routes their work through it. That number, multiplied by twelve, then by the years you intend to operate it, is the real cost of the decision. The build is a rounding error against it.

Second, instrument the run before you scale it. You cannot manage a cost you cannot see, and agent run costs are invisible by default because they hide inside aggregate cloud and API bills. You need per-task cost attribution — which agent, which task, how many steps, how many tokens, what it cost — the same way you need per-request tracing to manage latency. I made the technical case for this in instrumenting agents with OpenTelemetry, and the run-cost era turns that from a nice-to-have into the difference between a budget you control and a bill you receive. An agent you cannot cost per task is an agent you cannot govern.

Third, treat step count as a first-class cost lever, because it is the one you actually control. Since token consumption scales super-linearly with steps, the highest-leverage optimization is not a cheaper model — it is an agent that takes fewer steps to reach the same answer. Better planning, tighter tool design, context that gets pruned rather than accumulated, and hard step budgets that stop an agent from grinding through forty iterations on a task it should have escalated after five. The cheapest token is the one the agent never had to resend because it finished sooner.

Fourth, and this is the uncomfortable one: account for the human line. The oversight cost is real, it is recurring, and it does not go to zero as the models improve — it changes shape. Better models mean each agent needs less babysitting, but you run more agents, so the aggregate supervision load can stay flat or rise even as per-agent oversight falls. The person who used to do the work now supervises the fleet that does the work, and that person is not free. Budget them as a run cost, because that is what they are.

The build was never the moat

Step back far enough and the run-cost era resolves into a single reframe that I think will look obvious in hindsight. For the entire history of software, the expensive, defensible, differentiating part was the build. You hired the engineers, you shipped the product, and the running of it was a solved, commoditized afterthought — servers and bandwidth, cheap and predictable. Value lived in the artifact you built. That is the assumption baked into every pricing model, every budget line, every instinct about where software cost comes from.

Agents invert it. The build is commoditizing toward the cost of specifying what you want — a few weeks, a few tens of thousands of dollars, falling every quarter. The run is where the money is, where the variance is, where the moat is, and where the entire market is now rushing to compete. The company that makes long-horizon agents cheap to run wins more than a cost advantage; it wins the ability to let agents run longer, attempt harder tasks, and stay autonomous where a competitor has to cut them short to control the bill. Run cost is not a line item. It is the competitive surface of the whole category.

The token was the right unit for a technology that answered. It is the wrong unit for a technology that works, because work has duration, and duration has a cost that a single completion never captured. The meter is moving from the token to the task, from the completion to the run, from the thing you build to the thing you operate. The vendors quoting you build costs are quoting you the cheap number because it is the one that closes the deal. The number that decides whether the deal was smart is the one that arrives every month afterward, and it is time to start reading agents by that number instead.