The cost of an agent is not the price of the answer. It is the price of everything the system has to do before that answer becomes a reliable outcome.
If calling an AI model costs only a few cents, why can getting an agent to complete a task cost considerably more? Why does a coding agent spend so much time reading files, executing commands, and checking its own work? And why do companies invest so much engineering effort into systems built around models they don't even train?
The answer is that generating a plausible response and producing a reliable outcome are different problems.
An AI model can suggest how to fix a bug. An agent has to find the bug, understand the surrounding code, make the change, run the tests, interpret the failures, and decide whether its work is finished. What sounds like a small difference has enormous consequences for cost.
What Exactly Is an Agent Harness?
Consider asking a language model to write a Python function that sorts numbers. It receives your request and produces code. You copy that code into your editor, run it, and decide whether it works.
One request, one response.
Now suppose you ask an agent to fix a bug in an unfamiliar software repository. It needs to inspect the code, locate the problem, make a change, and test its work. If the tests fail, it needs to understand why and try again.
The model doesn't ordinarily contain a filesystem, terminal, browser, or test runner. Those capabilities are provided by the software surrounding it. This surrounding system is commonly called an agent harness.
At its simplest, a harness executes a loop. The model decides what to do. The harness executes the requested operation and returns the result. The model then decides what to do next. The process continues until it reaches an outcome or stops.
Model: Decide → Harness: Act → Environment: Observe ↺
Each observation can cause another model request. The harness controls the execution and feedback loop.
This loop can fit into surprisingly little code. But something that succeeds in a demonstration isn't necessarily something you can trust to run unattended. Reliable execution also requires permissions, state management, failure recovery, observability, and a way to establish that the task is actually done.
Why One Task Requires So Many Model Calls
The first reason agents become expensive is that a task rarely consists of one inference call. A coding agent may need a call to decide which file to inspect, another to interpret the file, several to plan and apply a change, and still more to diagnose test failures.
Each call has a cost determined by how much context the model reads and how many tokens it generates.
Here, and are the input and output tokens at step , and the prices are expressed per token. The total depends on the number of calls, the length of each request, and the model being used.
Later requests often need information from earlier ones. Once the agent has inspected five files, it may need to retain what it learned about those files before deciding what to do next. The task history grows, and without context management, each new call may reprocess an increasingly long record of earlier work.
This doesn't mean every earlier token has to be paid for at the full rate. Repeated prompt prefixes can benefit from prompt caching, and completed phases can be summarized or stored outside the model's context. But new tool results still need processing, generated tokens still cost money, and every additional decision is another inference step.
Tools Add Work, Not Just Capabilities
Suppose you ask a model why a website loads slowly. It can suggest possible causes from its training. An agent can instead open the website, inspect network requests, examine JavaScript, and run performance tests.
The evidence is useful. Rather than merely guessing, the agent can investigate what is happening. But browser sessions, code execution, external APIs, and persistent environments can have their own costs. Every observation can also create another model decision.
A slow JavaScript download, for instance, might lead the agent to inspect the file, check caching, and compare other pages. The cost comes from both running these operations and deciding which operation to perform next.
More tool calls aren't automatically wasteful. Sometimes the additional investigation is exactly what makes the final result trustworthy. The problem is knowing when the investigation has produced enough evidence to stop.
Small Errors Become Expensive in Long Tasks
Suppose each action in a task succeeds 98% of the time. This sounds like excellent reliability. But what happens if the task requires thirty dependent actions, and every action must succeed?
Under the assumption that each action succeeds independently, and one failure causes the entire task to fail, the chance of completing all thirty actions is only about 55%.
Real agent systems can recover from many failures, and actual errors may be correlated rather than independent. Nevertheless, the arithmetic explains why even a small error rate matters so much in long tasks.
Recovery adds more work. If a test fails, the agent may need to understand the error, revise its change, and rerun the tests. A failed attempt consumes tokens and compute without necessarily producing a completed task. Worse, an agent may not immediately recognize its mistake, and can spend several steps investigating the wrong problem.
What matters, then, isn't simply the price of a model call. It's the cost of all the attempts needed to finish successfully.
The Cheapest Model Isn't Necessarily the Cheapest Agent
Suppose two models are available. One is inexpensive but frequently chooses the wrong tool or misunderstands instructions. The other is more expensive but generally completes each operation successfully.
Choosing the cheaper model sounds reasonable until we consider how frequently the task has to be restarted. A small cost per call can become a large cost per successful outcome when a long sequence repeatedly fails near the end.
The experiment reveals something less obvious as well. Retries may increase the cost of an individual run while reducing the cost of eventually getting a successful result. This isn't a contradiction. Retries consume extra inference, but they can prevent the agent from throwing away all the work already done.
That doesn't mean retries are always a good idea. Repeating an impossible operation won't fix it. If an API call is failing because permissions are missing, a dozen retries only increase the bill. Good recovery requires diagnosing the failure, not merely performing the same action again.
The Hidden Cost of Reliability Engineering
The model bill is only one part of the expense. A harness that can modify a production database may need restricted permissions, confirmation for sensitive actions, logs of what changed, and a means of recovering from errors. A browser agent needs to cope with pages that load slowly or change unexpectedly. A coding agent needs to distinguish a test that passes from a task that was completed correctly.
These safeguards aren't new model capabilities. They are engineering work around the model.
They also have to be tested. An agent may take different valid paths toward the same result, so inspecting whether it followed a predetermined script isn't always enough. The outcome itself has to be evaluated. This is one reason agent evaluations are more involved than testing a simple question-answering interface.
It is relatively cheap to build a loop that works on a few favorable examples. Building one that survives unusual tool outputs, interrupted execution, and unexpected environments can be considerably more expensive.
Why Multiple Agents Can Cost Even More
One approach to complicated tasks is to use several agents. A research task, for instance, may assign different questions to separate agents while a coordinating agent compares their findings.
This can be useful when the work is genuinely parallel. But each agent consumes tokens, uses tools, and maintains its own context. Coordination introduces extra requests too.
In a 2025 engineering report, Anthropic described agents using about four times as many tokens as ordinary chat interactions, and multi-agent systems using about fifteen times as many in its observed workloads. These are measurements from Anthropic's own system, not universal cost multipliers for all architectures.
The report also found that multi-agent research worked particularly well for questions that could be divided into independent investigations. Tasks with many dependencies were less suitable. Adding more agents can increase spending without improving the result if they duplicate work or wait for one another.
Can We Make Harnesses Simpler?
There's another possibility worth considering. Perhaps some harnesses are expensive because developers add complexity that the task doesn't need.
A system can have planners, memories, specialized agents, critics, validators, and reflection stages. Each addition sounds useful on its own. But every additional call or component creates another opportunity for expense and failure.
A planning stage may help with a difficult research project and slow down a straightforward request. A second agent reviewing every answer might catch mistakes while introducing new ones. A memory system might retain useful context, or it might repeatedly supply irrelevant information.
In Building Effective Agents, Anthropic recommends beginning with simple approaches and adding more elaborate structures only when the task justifies them.
I think that's sensible. A reliable single model call is preferable to an elaborate agent if both accomplish the same thing. The value of a harness is not measured by how much activity it produces.
What Are We Actually Paying For?
The important distinction is between a plausible answer and reliable completion. A plausible answer can be cheap. Reliable completion may require investigation, feedback, error detection, recovery, and a credible stopping condition.
Each of these operations adds expense, but it can also make the difference between a useful agent and an impressive demonstration.
The economics should therefore be judged against the alternative way of completing the task. If an agent spends a few dollars solving a problem that otherwise consumes hours of engineering time, the expense may be justified. If an elaborate multi-agent system spends the same amount answering something a single call could handle, the added complexity is probably wasteful.
As models become more reliable and inference becomes cheaper, some expensive recovery loops may disappear. At the same time, improved systems will make it practical to delegate larger and more complicated tasks, which require their own forms of verification and control.
My expectation is that economical agent systems won't be the ones that reason the most or use the largest number of tools. They'll be the ones that know when additional work is necessary, when a simpler method is sufficient, and when the task is finished.
References
RESEARCH NOTES / SYSTEMS