What an AI agent costs to run, counted per task rather than per token

An agent that cost a few cents a run in the pilot can produce a monthly bill nobody predicted, and the bill is often not the model invoice. The price sheets quote dollars per million tokens. The business buys finished tasks: an invoice entered, a ticket answered, a report drafted. Between the two sit loops, tool results, retries and the person who checks the output. This article covers running costs once the agent is live. What it costs to build one is in what an AI MVP costs in 2026.

Count AI agent cost per task, not per token

A task is one unit of work the business would otherwise pay a person to do. Its cost is every model call made on its behalf, plus its share of hosting, plus the minutes a person spends reviewing it. The first two come from logs. The third comes from a stopwatch.

The model part is easy to measure exactly. Every API response carries a usage block with the tokens it consumed. On the Claude API that block separates uncached input, cache writes and cache reads, and output. Tag each call with the task it belongs to, multiply by the price list, and sum by task. Estimating from prompt length gets it wrong, because the expensive parts are the ones the prompt does not show.

Input and output are priced differently. At the time of writing (October 2026), Anthropic lists Claude Sonnet 5.5 at $2 per million input tokens and $10 per million output tokens on its pricing page, and the five-to-one ratio holds across its current models. An agent reads far more than it writes, so input usually dominates the token count while output costs more per token. Which one dominates the bill depends on the task, and the usage logs will tell you within a day.

How agent loops multiply calls

A chatbot answer is one call. An agent task is a loop: the model decides on a tool, the code runs it, the result goes back to the model, and the model decides again. A task that looks up a customer, reads an order, checks a policy and drafts a reply is five or six calls.

The API keeps no memory between calls. Each call re-sends the tool definitions, the system prompt and everything that happened earlier in the task. The sixth call pays again for everything the first five saw. Input tokens per task grow faster than the number of steps, roughly with its square, so a task that takes ten steps instead of five costs much more than twice as much.

The fixed part is larger than it looks. When a request includes tools, Anthropic adds a tool-use system prompt of a few hundred tokens on top of the tool definitions themselves, listed per model on the pricing page. Twenty tools with careful descriptions and parameter schemas can come to a few thousand tokens, sent on every call of every task. Give an agent the tools its job needs and no more.

Tool results inflate the context

Most of the growth in the figure is tool output. A database query that returns two hundred rows, a full web page, the text of a PDF: once a tool result enters the history, every later call in the task pays for it again. Web search adds a charge on top. On the Claude API it is priced per search and the results are counted as input tokens in that turn and in later ones.

The fixes are in the tools, not the prompt.

Instead of	Send
The whole record	The fields the model needs
Every row at once	One page, and let the model ask for the next
The full detail	An identifier and a short summary, with a second tool to fetch the detail when the model decides it needs it
A long result, once it has been used	A one-line note of what it said, in its place in the history

A tool that returns a tenth of the text costs a tenth as much on every later step, and the model usually decides better with less to read.

Retries, failures and the runs you throw away

Some calls fail. A response does not match the schema and is retried. A tool times out and the step runs again. A task loops until it hits the step limit and ends with nothing. Each of these costs tokens and produces no finished task.

So the useful number is cost per successful task: total spend divided by tasks completed, not by tasks started. A model that is cheaper per call but fails one task in five can cost more per success than a dearer one that rarely fails, before counting the person who cleans up after the failures. Structured output that validates on the first attempt is a cost saving as much as a quality one, which is the subject of getting reliable structured output from LLMs.

Two more sources of spend never appear in the product. The evaluation set runs on every change to the prompt or the model. Shadow mode, described in putting an AI agent inside an existing workflow, processes real work in parallel while producing nothing anyone uses. Both are worth their cost. Both belong in the budget.

Prompt caching and batch discounts

Because each call repeats a long prefix, caching that prefix is the largest single saving available for an agent. On the Claude API the cache is built in a fixed order, tools, then system prompt, then messages, and a hit needs an exact match of everything up to the cache marker. On OpenAI, caching is on by default for supported models.

Price, as a multiple of normal input	Anthropic	OpenAI
Cache write	1.25 times for the five-minute cache, 2 times for the one-hour cache	1.25 times
Cache read	0.1 times, and 0.05 times on Claude Sonnet 5.5 and Opus 5.5	0.1 times
Minimum prompt to cache	a minimum length; shorter prompts are not cached, and no error says so	1,024 tokens on recent models
Batch, input and output	0.5 times; most batches finish within an hour, up to 24 hours	0.5 times; up to 24 hours

Caching rewards a prefix that never changes. A timestamp or a user’s name near the top of the system prompt breaks it on every call. So does editing a tool description, which invalidates the whole cache. Put what is stable first and what varies last, and check the cache-read count in the usage block rather than assuming the cache works.

Batch processing halves the price in exchange for results that arrive later. That suits work nobody is waiting for: overnight reconciliation, re-processing last month’s documents, evaluation runs. It does not suit a loop where each step depends on the last, because each step would wait for its own batch. Anthropic’s pricing page notes that the caching and batch discounts stack.

Hosting, vector storage and the rest of the bill

The agent also needs somewhere to run: an orchestrator, a queue, a database, credentials for the systems it touches. For most agents that is a fixed monthly amount that barely moves with task count.

Two items do grow. Vector storage grows with the documents you index and is billed by volume and queries, and changing the embedding model means paying to embed everything again. Logs grow with every task, and agent logs are large, because useful ones keep the full prompt, every tool result and every response. Keeping them for a month is cheap; keeping them forever without deciding to is not. What to record and how long to keep it is covered in LLM observability in production.

Human review is usually the largest cost

The line that most often exceeds the model bill is the person who checks the output. Review cost is the share of tasks a person looks at, times the minutes each review takes, times what an hour of that person costs. All three can be designed.

The minutes depend on the review screen. In the invoice pipeline we built for bilz.ai as its technology partner, every extracted number links back to the region of the document it came from, so a person checks a value by looking at one highlighted patch of the page rather than reading the whole invoice. The share reviewed depends on how much the agent is trusted, which should start high and come down as the error rate on recent cases allows. A review queue sorted with the uncertain cases first lets a person spend their minutes where the errors are.

A worked example, with hypothetical numbers

Say an agent handles a task in six calls. The tool definitions and system prompt come to 4,000 tokens. Each step returns a 1,500-token tool result, and the model writes 300 tokens per call. The first call sends 4,000 tokens of input and the sixth sends 13,000. Say a person reviews 30% of tasks, at 90 seconds each, and their time costs $40 an hour. At the Claude Sonnet 5.5 list prices above, for 2,000 tasks a month:

Line	Per task	Per month
Input without caching, 51,000 tokens	about $0.10
Output, 1,800 tokens	about $0.02
Model without caching	$0.12
Model with caching on every step: 38,000 tokens read from cache, 13,000 written	about $0.05
Model with one task in ten failing and running again	about $0.06 per successful task	about $120
Review: 600 reviews, 15 hours		$600

Review is five times the model bill. Switching to a model at half the price saves about $60. Cutting the reviewed share from 30% to 10% saves about $400. The second change is where the effort belongs, and it is mostly evaluation and interface work rather than model choice. When a cheaper model can take some of the steps, routing between cheap and frontier models covers how to split them.

Set a budget per task and alert on it

A monthly limit at the provider is a backstop, not a control. It acts on the total, after the money is spent, and cannot tell you which task caused it. Anthropic’s Usage and Cost API breaks usage down by API key, workspace and model, reports cost in daily buckets, and its data usually arrives within about five minutes. A separate key or workspace per agent makes that reconciliation possible. It still knows nothing about tasks.

The control lives in the agent’s own code. Give each task a ceiling on steps and on tokens. When a task reaches it, stop, record why, and hand the task to a person, because a task that has used three times its usual budget is usually stuck in a loop rather than close to finishing.

Store the cost of every task next to its result. Alert on cost per task at the 95th percentile and on the daily total against a forecast from task volume. A change in the prompt, a new tool or a provider’s model update shows up there first, often days before it shows up as a quality problem.

Compare it with the process it replaces

The agent’s cost per task means little on its own. Before building, time the current process: how long a person takes per task, what an hour of their time costs, and how often their work is corrected later. In the example above, if a person took six minutes per task by hand, 2,000 tasks would be 200 hours and $8,000 a month, against roughly $720 for the agent plus its fixed hosting. That gap is the case for the project, and its size tells you how much review you can afford while the agent earns trust.

If you cannot measure the current cost per task, measure it before you build the agent. The AI agents and automation page describes how we scope and run that work, and you can write to us with the workflow and its volume.