How much does an AI agent cost to run?

A chatbot answers a turn. An agent pursues an outcome: it selects a tool, inspects the result, revises a plan, recovers from an error, and eventually produces a response. Every model call adds billed tokens, and every step can carry more working context than the last one.

This is why a prototype completes one task for pennies while hiding the repeated calls and failed runs that show up under real load. The useful question is never what one prompt costs. It is what one successful task costs.

What makes an agent more expensive than a chatbot?

The loop, not the question. A chatbot turn has one primary generation. An agentic task contains planning, tool selection, observation, correction and finalization, and each model request lands on the provider bill.

That decoupling from question size surprises people. A short request can trigger a long search, several tool results and a retry. A long request can be cheap if a single call resolves it. Input and output tokens are the billing units, so the bill follows the requests and the context inside them.

Anthropic's engineering account reports that agents typically use about 4x more tokens than chat interactions, and that multi-agent systems use about 15x. These are token-use multipliers observed in one engineering system, not universal price guarantees.

How does context make the bill grow?

Because the loop resends prior instructions, plans, tool results and intermediate outputs on later steps, and the provider bills those tokens every time. A growing transcript makes late iterations cost more than early ones, which is the opposite of what most cost models assume.

A tool output is not free just because the tool is free. Carry a large result into the next model call and it becomes part of that call's billed context. Verbose traces, duplicated documents, and superseded attempts all do the same thing.

Context quality pushes in the same direction as cost, which is convenient. Adding more material can reduce model performance, as context rot covers, so both concerns point at one action: keep what the next decision needs and drop the rest.

How much more do multi-agent systems cost?

Delegation adds model calls and coordination context on top of each subagent's own work. Anthropic reports approximately 15x the token use of chat interactions for its research system. That multiplier describes token consumption rather than a fixed invoice, since model selection and rates determine what you actually pay.

The same system, with a Claude Opus 4 lead agent and Sonnet 4 subagents, outperformed single-agent Opus 4 by 90.2% on an internal research evaluation. The engineering post is not peer-reviewed, and the honest reading is narrow: extra token consumption can buy materially better performance on a task built for parallel research. It does not establish that every multi-agent design earns its cost.

This comparison is economic, not architectural. The failure modes and design trade-offs live in when not to build a multi-agent system; the question here is how much billed work your chosen architecture needs for one outcome.

How should you estimate cost per task?

Sum every model request in a representative execution: planning, tool interpretation, retries, subagent work, and the final response. Separate input and output token totals by model, apply your provider's current rates at the time you decide, and divide spend by successful completions.

A useful measurement record carries the task identifier, model, input and output token counts, tool calls, retry count, termination reason, and success state.

Measure the distribution, not one happy-path trace. The median shows the common path; the upper tail is where long tool outputs, repeated corrections and pathological loops live. And failed executions consume full-price billed work while producing nothing, which is exactly why per-call averages flatter a system that fails often.

The trap worth naming: do not forecast production by multiplying a chatbot demo's one-call cost. Record a full task trace, replay representative inputs, and include the runs that failed.

When is the cost justified?

When the value of a completed task exceeds the cost of the full loop that produced it. Anthropic frames multi-agent as suited to tasks "where the value of the task is high enough to pay for the increased performance," specifically ones with heavy parallelization, information exceeding a single context window, or many complex tools.

Compare alternatives on the same outcome rather than on the same prompt. Measure a single model call, a single-agent loop and a multi-agent loop against your success criteria, then compare successful-completion cost, human review, latency and the consequences of failure. A cheaper architecture that needs constant correction is not cheaper at the product level.

Keep cost and price distinct. This post is about what the system consumes; the floor rule for pricing an AI service is about what you must charge once you know that number. Confusing them yields a price that looks competitive and loses money on every successful run.

Which levers actually reduce it?

The fastest wins remove unnecessary billed context and unnecessary iterations without moving the success criterion. Work from trace data, change one control at a time, and re-run the same evaluation set. The target is lower cost per successful task, not a lower token count bought with more failures.

• Shorten what the loop carries forward. Keep decisions, evidence and unresolved actions the next step needs.
• Cap the steps. Terminate with an explicit failure state when the agent stops making progress.
• Use a cheaper model for mechanical sub-steps. Reserve the capable model for decisions that affect quality.
• Cache the stable prefix where your provider supports it, so fixed instructions and reference material are not recomputed.
• Measure cost per successful task. Report failed runs, retries and partial outcomes rather than burying them in a per-call average.

A structured execution trace exposes all of this before production. It should make every model request, tool result, retry and termination reason inspectable, because an invoice tells you the amount spent and nothing about the loop behavior that spent it.

What should you measure before production?

Token use and success rate across representative tasks, including difficult inputs and tool failures, recorded across the complete execution graph rather than the final call alone. A production decision needs a cost-per-successful-task distribution and a threshold for when the system stops, escalates, or returns failure.

On BrowseComp, Anthropic reports that token usage alone explained 80% of the variance in performance, and that token usage, model choice and tool calls together explained 95%. Those come from their engineering post and internal analysis, so they do not predict your workload, but they do name the variables your evaluation should expose.

If the extra billed work produces enough value, keep the architecture. If it does not, shorten the loop, simplify the design, or decline the task. A cheap demo proves the path works. It proves nothing about whether the economics do.