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.
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:
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.
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.
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.
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.
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.
You can get within a reasonable band before writing code, provided you do the work on paper first:
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.
Once you have measured numbers, most savings come from a short list:
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.
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.
Originally published on the Pykero blog.