The Cost to Run an AI Agent: Price the Whole Loop, Not the Tokens

The cost to run an AI agent is rarely dominated by the model. In the agents we scope and build, the large lines are the tool calls wrapped around the model (search, scraping, data enrichment, email verification), the retries that re-bill those tools, and the hosting and tracing you need before you trust the thing to run unattended. If you want a number you can defend to a board, price the whole loop per completed task and treat the per-million-token price as one input among six.

What a single agent task actually buys

Take a plain example: an agent that qualifies an inbound lead. One run might fetch the prospect's website through a scraping API, run two or three web searches, pull company data from an enrichment provider, verify an email address, and make three or four model calls to plan, extract, draft and check. Every one of those is a metered event. The model is the only one you probably priced.

The full bill of materials for one task usually looks like this:

• Model tokens, split into input, output and cached input, across every call in the loop
• Tool and API calls, each with its own per-request price or a seat licence with a quota
• Retries and re-runs caused by tool timeouts, malformed model output or rate limits
• Infrastructure: queue, workers, database, vector store if you use one
• Observability: tracing spans and log retention, often priced per event
• Human review time for the share of tasks that get flagged

The catch with agents, as opposed to a fixed pipeline, is that the agent decides how many tool calls to make. Your cost per task is a distribution, not a number. Two tasks that look identical from the outside can differ several-fold in cost because one of them searched five times and the other searched once.

Why tool calls outgrow tokens

Token prices have fallen steadily, and you can cut them further with prompt caching and batch processing. Anthropic documents both on its pricing page. Per-request API prices for search, scraping and enrichment do not move that way. They are metered per call, priced for machine consumption, and the agent calls them repeatedly where a human would have skimmed one page.

The market is moving in the same direction. Brave recently announced that its Search API accepts agentic payments through the x402 protocol, which is a tool vendor explicitly designing for agents that pay per call without a human in the loop. Expect more of your agent's suppliers to bill this way. That is convenient for the agent and dangerous for the budget unless you cap it.

Caching helps the model side only. The model reads your system prompt once and the cache absorbs the repeats. A third-party API call is never cached unless you build that cache yourself, keyed on domain, query or record, with a sensible expiry.

What we learned on our own outreach engine

We run an internal outreach tool that scrapes each prospect's site and writes one tailored email per company. The first real design question was the marginal cost per prospect, because the per-page scraping price and the per-call model price both scaled with the list. We ended up self-hosting Firecrawl and running a local model, so the marginal cost per prospect is mostly compute we already pay for. The second finding was less obvious: a single call that extracts the facts and drafts the email in one pass beat a multi-step chain on both cost and quality. Fewer calls meant fewer places to fail, which meant fewer retries, which is where the chain had been quietly spending. We wrote up the general pattern in single call vs agent chains.

The retry multiplier

Retries are the line nobody budgets. A scraping API times out, the model returns JSON with a trailing comma, a rate limit fires on the third search. Each retry re-bills everything inside the loop it restarts. If your retry policy wraps the whole task rather than the failing step, one flaky tool can triple the cost of that task.

Two metrics catch this early. The first is tool calls per completed task, tracked as a distribution with its tail, not just a mean. The second is attempts per completed task, which tells you how often the loop restarted. When the tail of either grows, your bill grows before your dashboards do. Hard caps on both, enforced in code rather than in the prompt, are the single cheapest control. Making paid actions idempotent so a re-run does not repeat them matters just as much, and we covered that in AI agent duplicate actions and idempotency.

Fixed costs that look small until you scale down

A queue, two workers, a Postgres instance and a tracing platform are cheap in absolute terms. Divided across a few thousand tasks a month they are nearly free. Divided across two hundred tasks a month they can cost more per task than every API call combined. Tracing platforms that bill per span are the sharpest version of this: an agent with twelve steps emits twelve spans per task, plus retries.

Which regime you are in decides most of your architecture. At low volume, a managed agent runtime that charges per run is often cheaper than running your own stack, and the fixed costs disappear into someone else's margin. At high volume the arithmetic flips and self-hosting the heavy tools starts to pay. The trade-offs are laid out in managed vs self-hosted agent runtimes.

How to estimate before you build

You can get within a reasonable band before writing code, provided you do the work on paper first:

1. Write the loop as a list of calls. For each step, note the provider and the expected range of calls per task (minimum, typical, worst case).
2. Price each step at list price. Mark which are per-call, which are per-seat with a quota, and which are fixed monthly.
3. Multiply by expected attempts. Pick an honest retry assumption for the pilot and replace it with measured data within the first week.
4. Spread fixed costs across monthly volume. Infrastructure, tracing and any licences, divided by the number of completed tasks you actually expect, not the number in the pitch deck.
5. Compare against the value of one completed task. If a qualified lead or a resolved ticket is worth less than the worst-case cost of producing it, redesign the loop before building it.

Then run a pilot of a few hundred tasks with cost tracking per step turned on from day one. The pilot exists to replace your guesses in steps one and three. If you only track tokens during the pilot, you will go to production with a model bill you understand and a tool bill you do not.

Levers that actually move the bill

Once you have measured numbers, most savings come from a short list:

• Collapse steps. Every model call you remove also removes its retries and its spans.
• Cache tool results. Scrape a domain once and reuse it across tasks. Give search results a time-to-live measured in days for anything that is not news.
• Self-host the heavy tool when volume justifies it. Scraping and small extraction models are the usual candidates, as in our outreach engine.
• Batch anything that is not urgent. Overnight enrichment and classification can run through discounted batch endpoints instead of live calls.
• Cap tool calls per task in code. A prompt instruction to "search at most three times" is advice. A counter in the loop is a control.
• Route by step. Use a small model for extraction and formatting and reserve the frontier model for the judgement call, following the reasoning in small LLM vs frontier model.

Note that the token-focused advice in most cost guides sits at the bottom of this list for agents. It is still worth doing, and we keep a separate guide to LLM cost optimisation, but it addresses the smaller bill.

What to ask before you sign

If a vendor or agency quotes you a token price and a monthly platform fee, the estimate is incomplete. Ask for the projected cost per completed task and the assumptions behind it. Ask how many tool calls a typical task makes and what the worst case looks like. Ask how retries are capped and whether paid actions are idempotent. Ask which costs are fixed and what happens to per-task cost if your volume is half what you planned.

A team that has run an agent in production will answer those questions with numbers from a dashboard. A team that has only built demos will answer with token prices. If you are pricing an agent right now and want a second opinion on the loop before you commit to a stack, let's talk.