How to Cost an AI Agent Before You Build It

What an agent run actually costs

Most agent estimates are one multiplication: tokens times a price found on a pricing page. That number is real and it is a fraction of the bill. The rest hides in retries, in tool providers that charge per call, in the eval suite that runs inference every night, and in the person who reads the escalation queue. This guide gives you the arithmetic and the lines people forget.

The five lines in a loaded run

Price the run, not the model call. A loaded run is one unit of work carried end to end, including everything that had to happen around the model for the output to be usable. If your estimate has one line in it, it is not an estimate of anything a finance team recognises.

Why input tokens grow faster than the step count

In a tool-calling loop, every step re-sends the entire conversation so far. The static prefix, the system prompt and the tool schemas go up on every call, and so does each earlier assistant message and each tool result. If the prefix is S tokens and each step adds A tokens of new material, total input billed across n steps is about nS + An(n-1)/2. The second term is quadratic, which is why a loop that takes twice as many steps costs more than twice as much.

Two consequences follow. Anything that lengthens the transcript is charged again at every remaining step, so a single fat tool result is not a one-off cost. And the cheapest reliability work is often the cheapest cost work, because a step you did not need to take removes its own tokens plus its share of every later re-send.

Where the money hides

Six lines get missed in most agent estimates. None of them are exotic. They are simply invisible in a demo, because a demo runs the happy path once and never runs a nightly eval suite.

Run it on your own numbers

The two prices below are stand-in figures, chosen only so the arithmetic runs. Replace them with your provider's current published rates before you trust the output, and keep those rates in config with the date you checked them.

Push the step count from eight to sixteen and watch what happens. That single field usually moves the monthly figure more than switching model tiers does, which is why step discipline beats price shopping. Then add the other four lines from the loaded run by hand; this calculator covers tokens only, and tokens are the part that flatters you.

Cost controls that do not make the agent worse

Cut tokens where the model does not need them, never where it does. Every control below is measured against your eval set before and after, because a change that saves twenty percent and loses five points of accuracy costs money once you divide by the acceptance rate.

Truncate tool results before they enter the transcript

This is the largest lever in most systems. A raw API response of eight thousand tokens, returned at step two of a ten-step loop, is charged nine more times. Return the fields the agent reasons over, keep the full payload out of band behind an identifier, and give the agent a tool to fetch specific parts if it ever needs them.

Cache the static prefix, and never reorder it

Providers price cached input below fresh input, and caching keys on an exact prefix match. One dynamic value near the top of the prompt, a timestamp or a user name or tool definitions serialised in a different order, breaks the match for the whole run. Put the static system prompt and tool schemas first, dynamic context last, and check your provider's current cache pricing and minimum cacheable length, because both change.

Route steps to different models

Classification, routing and field extraction rarely need your best model. Planning and final synthesis usually do. Split the loop so cheap steps run cheap, then re-run the eval set to confirm the small model holds on those steps specifically, not on the task as a whole.

Cap the loop and fail visibly

A step ceiling turns an unbounded worst case into a bounded one, which is what makes a forecast possible at all. The run that hits the ceiling is the most expensive run you have, so alert on the rate rather than logging it quietly.

Instrument the cost before you tune it

Write a cost record per run from the first day, not after somebody asks why the bill moved. It costs an afternoon at the start and is close to impossible to reconstruct later, because provider invoices arrive aggregated and cannot be split by ticket.

{
  "run_id": "run_01J9KQ7Z8M",
  "unit_of_work": { "type": "support_ticket", "id": "t_55219" },
  "agent": "support-triage",
  "steps": [
    { "n": 1, "model": "small", "in": 1840, "cached_in": 1500, "out": 96 },
    { "n": 2, "model": "small", "in": 2610, "cached_in": 1500, "out": 142 },
    { "n": 3, "model": "large", "in": 4380, "cached_in": 1500, "out": 380 }
  ],
  "tool_calls": { "search": 4, "enrich": 1, "crm_write": 1 },
  "prices": {
    "source": "config/pricing.yaml",
    "checked_on": "2026-08-19",
    "note": "read at run time, never hardcoded in the agent"
  },
  "outcome": {
    "status": "accepted",
    "retries_on_invalid_output": 1,
    "hit_step_cap": false,
    "human_review_minutes": 0.0
  }
}

The field that matters most is unit_of_work. Without it you can compute cost per run, which is the number that flatters you, but never cost per resolved ticket, which is the number somebody will ask for. Recording retries_on_invalid_output and hit_step_cap alongside it lets you separate expensive work from expensive failure, and those two have completely different fixes. Reading prices from config with a checked_on date keeps the ledger honest when a provider changes a rate.

Building an estimate you can defend

1. Name the unit of workbefore anything else

   One resolved ticket, one processed invoice, one qualified lead. Every number afterwards is per unit, and teams that skip this end up comparing cost per run against a colleague's cost per outcome.

2. Pull twenty real cases from the last month

   Real ones, including the awkward ones people complain about. Synthetic cases are shorter, cleaner and cheaper than reality, which is exactly how estimates end up half of what production charges.

3. Spike the loop and record per-step usage

   A rough agent is enough. What you need is the shape: how many steps, how large the tool results, how often the output fails to parse. Take token counts from the provider's usage fields.

4. Take the median and the 95th percentile

   Quote both. Budget on the 95th, because the tail is where the step cap and the retries live, and the tail is what a monthly invoice actually reflects.

5. Add the other four lines with named assumptions

   Tool calls per run times published rates, infrastructure divided by expected volume, review minutes times a loaded hourly rate. Write each assumption next to its number so anyone can argue with it.

6. Re-measure two weeks after launch

   Real traffic is more varied than your twenty cases. The first fortnight tells you whether the acceptance rate holds and whether the step distribution has a longer tail than the spike suggested.

• Estimating on the happy path. Failed runs usually reach the step cap, so they cost more than successful ones, and accuracy improvements cut the bill twice.
• Forgetting the eval bill. A nightly suite over a growing golden set is inference, and it can outspend production traffic in a low-volume system.
• Treating prices as fixed. Put every rate in config with the date it was checked, and re-run the estimate when a provider changes one.
• Ignoring context growth. A knowledge base that doubles usually doubles retrieved context in every step, so retrieval size belongs in the forecast.
• Comparing models on price per token rather than on cost per accepted outcome over the same case set.

Terms worth being precise about

Definitions

Cost per accepted outcome

The total cost of one unit of work divided by the fraction of runs whose output is accepted without rework. It is the only cost figure that stays honest when accuracy changes, because rejected runs are charged in full and deliver nothing.

Loaded run

The full cost of carrying one unit of work end to end: model tokens, paid tool calls, a share of standing infrastructure, human minutes, and remediation. A token-only estimate is a lower bound on a loaded run, not an estimate of one.

Prefix caching

A provider feature that charges less for the leading portion of a prompt when it matches a previous request exactly. It only works on an exact prefix, so any dynamic content placed before the static system prompt and tool schemas removes the discount.

Step cap

A hard ceiling on the number of model calls in one agent run, enforced in code rather than by instruction. It converts an unbounded worst case into a bounded one, which is what makes a per-run budget forecastable.

Transcript growth

The effect of a tool-calling loop re-sending the whole conversation on every step, so input tokens accumulate roughly with the square of the step count. It is why a single large tool result is charged once for every step that follows it.

Before you commit to a number

Work through this before the figure leaves your team, because a cost estimate becomes a commitment the moment somebody writes it in a plan. Most of it takes a day, and the alternative is explaining a bill nobody predicted. If the arithmetic says the numbers do not work, that is a finding: some jobs are better as a fixed pipeline, which agent or workflow covers.

Two related pieces: agent permissions and scope covers the budget ceilings that stop a stuck loop from spending the month in an afternoon, and token cost arithmetic works through the token maths on its own. Our AI agent development work starts with this estimate rather than ending with it.