Services
Work
Our Process
Blog
Tools
FAQ
Contact Sales

HorizonLux · AI agents

Agents that survive their own invoice

Iteration caps, circuit breakers and context policy as defaults, not as hardening tasks scheduled for later.

Get a cost review
Guides

AI Agent Costs: Why One Run Costs 25x a Single Call

AI agent costs explained. Why one run costs 19x to 50x a single API call, where the tokens actually go, and the four controls that bring it back down.

Agent step costs rising as a staircase, with carried context taking a larger share of every step
Seif Sgayer
Seif Sgayer
Jul 27, 2026 · 19 min read

TL;DR

AI agent costs, or agentic AI cost if you prefer the vendor phrasing, are not a model pricing problem. They are a geometry problem. An agent does not send one request per task, it sends one per step, and each step re-sends everything before it: the system prompt, the tool definitions, every prior thought and every tool result. Total input tokens therefore grow with roughly the square of the step count, not in a straight line.

That is why a twelve-step run on a frontier model commonly costs 20x to 30x the same task as a single completion, and why a thirty-step run passes 100x. Retries multiply on top, because a failed step re-sends the same large context and is billed again.

Four controls fix most of it, in this order: cap the iterations, stop carrying the full transcript, cache the system prompt, and break the retry loop. The step count is almost always the biggest of the four, because the steps you remove are the most expensive ones in the run.

Building agents that have to survive their own invoice? We design AI agents around cost per completed task, with iteration caps and circuit breakers as defaults rather than hardening tasks.

Key Takeaways

  • An agent run costs 19x to 50x a single API call on typical settings, and the multiple is set by your step count, not your model.
  • Input tokens grow with the square of the step count, because each step re-sends the accumulated conversation.
  • On a twelve-step run with a full transcript, over half of all input tokens are re-sent conversation rather than new information.
  • Cutting a run from twelve steps to six removes far more than half the cost, since the steps removed carried the most context.
  • Retries are billed in full and usually logged once, so provider request counts exceed application event counts.
  • The system prompt is the most re-read span you own, which makes agents the strongest case for prompt caching.
  • In a chatbot the user owns the loop, so you cannot cap iterations. Summarise on a threshold and watch cost per user instead.

How much do AI agents cost?

The cost of running AI agents is the question we are asked most, and it has the least satisfying answer.

One disambiguation first, because the phrase covers two different bills. Building an agent is a one-off engineering cost, anywhere from a few thousand dollars to six figures depending on scope. Running one is a recurring per-run cost that scales with usage, and it is the bill that surprises people, because it behaves nothing like the flat SaaS pricing teams expect. This post is about the running cost.

There is no honest per-month figure, because the same agent doing the same job can differ by more than tenfold between two teams on identical model pricing. What decides it is four things: how many steps a run takes, how large the fixed prefix is, what travels between steps, and how often steps fail.

The useful way to express agent cost is therefore not dollars but a multiple: what one completed run costs against one plain completion of the same task. That number is portable, it survives a model price change, and it tells you immediately whether you have a problem.

On a common configuration, a twelve-step agent, a 4,000-token system prompt with tools, 600 new tokens and 400 output tokens per step, a full transcript carried between steps and a 15% retry rate, the multiple lands around 25x. Change nothing except the step count and it moves violently: three steps gives about 4x, thirty steps gives well over 100x.

Input tokens per agent step, split into system prompt, carried context and new informationTwelve bars, one per step of a single agent run, showing the input tokens each step sends. Every bar contains three bands. A constant dark band at the base is the system prompt and tool definitions, identical on every step. A bright band above it is carried context, the conversation so far being re-sent, and it grows taller with every step until it dominates the bar. A thin band at the top is the genuinely new information that step contributes. By the final step the new information is a small fraction of what is being paid for, and the run has spent more on repeating itself than on anything new.What each step is actually paying forstep 1step 12system prompt, identical every stepcarried contextactually newThe green sliver is the only part of step 12 that did not exist at step 11.You are not buying twelve requests. You are buying a staircase.
Same three bands in every bar. Only one of them is doing new work.

Why the cost grows with the square of the steps

This is the part worth internalising, because everything else follows from it.

Call the fixed prefix P, the new tokens each step contributes F, and the output each step produces O. Step one sends P + F. Step two sends P + F plus everything step one produced. Step three sends P + F plus everything from steps one and two. By step n you are sending:

P + F + (n − 1) × (F + O)

Sum that across all n steps and the carried portion contains a term proportional to n². In plain terms: double the steps and you roughly quadruple the input bill. A twelve-step run does not cost twelve times a one-step run, it costs something closer to seventy times it, before retries.

Two consequences fall straight out, and both are counterintuitive enough that teams get them wrong:

  • The last steps are the expensive ones. Step twelve can cost three to five times what step one cost, for exactly the same amount of thinking. So capping a run at six steps removes much more than half the cost.
  • Your agent spends most of its money repeating itself. On a twelve-step full-transcript run, more than half of all input tokens are conversation being re-sent. Not reasoning, not tool results, just the same words travelling again.

Where agent tokens actually go

Before optimising, it is worth being precise about which line is which, because three of these four are invisible in a demo.

What you are paying for Grows with Typical share of a 12-step run
System prompt and tool definitions Steps, linearly Large early, small late, and highly cacheable
Carried conversation Steps, quadratically The majority by the end of a run
Genuinely new input (tool results, user turn) Steps, linearly A small, shrinking slice of AI agent token cost
Output tokens Steps, linearly Small in volume, but priced 4x to 5x input
Retries Failure rate Pure surcharge on everything above

The important column is the middle one. Anything that grows quadratically will eventually dominate anything that grows linearly, which is why step count and context strategy beat model choice on agent workloads almost every time.

Put your own numbers in and the estimator below will compute the multiple, the monthly figure, and the per-step breakdown for your agent specifically.

Model calls to finish one task.

Completed tasks, not API calls.

What travels between steps

Every step re-sends everything before it. The default in most frameworks.

Refine the inputs

Repeats on every step.

Tool results, user turn.

Costs 4x to 5x input.

Steps that fail and re-send the same context.

Tool selection, routing, extraction.

One run costs
25.3xa single call
$0.501 per run vs $0.020 for one completion
Monthly
$10,019
139.4K input · 5.5K output
54% of input tokens are re-sent conversation, not new information.
Open the full estimator

Where the run gets expensive

Input tokens per step. The dark band is your system prompt, the bright band is conversation being re-sent, and the thin band at the end is the only genuinely new information in that step.

step 1 · $0.020step 12 · $0.053
system prompt carried context new this step

What each control is worth

Each figure is this model re-run with that one thing changed, so it is a real delta rather than a rule of thumb. They are not additive.

  1. Cap iterations at 6saves $6,251/mo
  2. Route half the steps to a small modelsaves $4,759/mo
  3. Cache the system promptsaves $2,663/mo

The four controls, in the order that pays

1. Cap the iterations, because agent cost optimization starts with the loop

The single biggest lever, and usually a small change.

An agent that is permitted to keep trying will keep trying. Without a hard ceiling it will grind through fifteen steps on a task that needed four, and every one of those steps is a billable call carrying everything before it. Your demo finished in three steps because the demo input was clean. Production input is not clean.

Set a hard agent iteration limit, and make exceeding it a loud, handled failure rather than a silent budget event. An agent that cannot fail loudly will fail expensively, and it will do it at three in the morning.

Watch the distribution, not the average. Agent cost is heavily long-tailed: most runs are cheap and a small fraction cost thirty times the median. An average hides exactly the runs that are hurting you, so look at the 95th percentile of cost per completed task.

A right-skewed distribution of agent run costs where the mean describes almost no runA histogram of the cost of individual agent runs. Most runs cluster in a tall group at the cheap end, and a long thin tail of expensive runs stretches far to the right. Three vertical markers are placed on the axis. The median sits inside the tall cluster where most runs actually are. The mean sits well to the right of it, dragged out by the tail, in a region where the bars are almost empty, so the average describes a run that hardly ever happens. The ninety-fifth percentile sits far out in the tail and marks the expensive runs that decide the monthly bill. The diagram shows why reading the average of agent cost hides exactly the runs that hurt.Cost of one agent run, across a week of runsmedianmeanp95almost no run costs thisthese decide the billcost per runThe tail is thin and it is where the money is. The average sits in the empty space between.Alert on p95. An average that looks healthy can hide a runaway loop.
The mean is not a run that happens. It is the median dragged rightward by the tail.

2. Stop carrying the full transcript

The default in most agent frameworks is to append every message to a list and send the list. It is the simplest thing that works, and it is the reason the curve is quadratic.

The alternative is cheap and rarely hurts quality: keep the last few turns verbatim, replace everything older with a running summary, and drop tool results once they have been consumed. Agent memory is a budget you set, not a property you inherit. A 40,000-token trace that a step does not need is not thoroughness. It is waste with good intentions.

Cumulative input tokens across a run under three context strategiesThree curves showing cumulative input tokens as an agent run progresses through twelve steps. Carrying the full transcript produces a curve that bends upward increasingly steeply, because each step adds more than the last. Keeping a running summary plus the most recent turns produces a much flatter, near-linear line. Keeping only a short window of recent turns is flatter still, but the agent forgets earlier context, which is why it is not always the right answer. The gap between the full transcript curve and the summary line at the end of the run is the saving available from changing what travels between steps, without changing the model or the number of steps.Cumulative input tokens, same twelve stepsfullsummarywindowthis gap is freestepsSame model, same step count. The only change is what travels between steps.A window forgets. A summary usually does not, and costs almost the same.
Three strategies, one workload. The curve is a choice, not a property of agents.

The window strategy is cheapest and is the one to be careful with: an agent that has forgotten why it started will happily redo work, which puts the steps back. Summary plus a short window is the setting that survives contact with production.

3. Cache the system prompt

Agents are the best possible case for prompt caching, and it is the least invasive change on this list.

Your system prompt and tool definitions are byte-identical on every step of every run. That is the most re-read span you own. Cached tokens bill at roughly 10% of the standard input price, so the prefix stops mattering almost entirely. Better still, the saving grows with step count, which is the opposite of most optimisations.

Two implementation notes. Put the stable content first and the variable content last, because caching works on prefixes. And check your provider's TTL against how frequently your agent actually runs: on a short default TTL, an agent that fires every few minutes may pay the write premium repeatedly and never collect a read. The mechanics and break-even math are in the prompt caching guide.

4. Break the retry loop

Retries are the most common invisible cost in an agent, because most logging records the outcome of an operation rather than every attempt inside it.

A tool call that fails schema validation is retried. A timeout is retried by the SDK. A malformed JSON response gets one more attempt. Each of those re-sends the full accumulated context and is billed in full, and all three can appear in your logs as one successful event.

The gap between an application event count and a provider request count, which is the retry billTwo horizontal bars drawn on the same scale for the same one week window. The upper bar is what the application logged: one thousand completed tasks. The lower bar is what the provider billed: one thousand seven hundred and forty requests, so it extends well past the first. The overhanging section is shaded separately and labelled as seven hundred and forty retries that were never logged, because most instrumentation records the outcome of an operation rather than every attempt inside it. The diagram shows that the difference between these two counts is a measurement that takes minutes to run and reveals a cost centre that is otherwise invisible.One week, two counts that should matchYOUR EVENT LOG1,000 completed tasksPROVIDER DASHBOARD1,740 billed requests740 retries nobody loggedBoth numbers already exist. Almost nobody puts them side by side.
Your logs record outcomes. The invoice records attempts. The overhang is the difference.

The specific pattern to break is an agent retrying the same failing call with the same arguments and expecting a different outcome. A circuit breaker on repeat-identical failures costs an afternoon and removes the single most common cause of a runaway agent and the invoice that follows it. To find out whether this is you, compare your provider's request count against your own event count for the same window: the gap is retries.

Should agent steps run on a smaller model?

Often, yes, but this is the fourth lever rather than the first, and applying it before the others just makes the wrong thing cheaper.

Most steps in an agent are not reasoning. They are tool selection, argument construction, routing decisions and short extractions. NVIDIA's 2025 research on small language models in agentic systems puts a small model at 10x to 30x cheaper on exactly that kind of narrow work, and frequently just as accurate, because a specialist beats a generalist on its home turf.

The architecture that works is small-model-by-default with escalation: run the cheap model on every step, and promote a single turn to the frontier model only when confidence is low, a schema fails, or a tool call will not parse.

One caution that matters more here than anywhere else. A weak model in an agent loop does not simply produce a worse answer, it produces a failed step, which triggers a retry, which re-sends the whole context. A cheaper model that fails 20% of the time can cost more than a strong model that fails 2% of the time. Measure cost per completed task, never price per token. How wide the price gap has to be before that stops being true is worked out in small language models vs LLMs.

Multi-agent systems

Multi agent architectures cost more than a single agent doing the same work, and usually by more than the agent count suggests.

Each agent carries its own system prompt and its own tool definitions, so the fixed prefix is paid once per agent rather than once per system. Handoffs make it worse: context that would have stayed in one accumulating thread instead gets serialised and re-sent across a boundary, where it arrives as fresh tokens on the receiving side and starts accumulating again.

One agent paying a single prefix beside three agents each paying their own plus handoffsTwo arrangements compared. On the left, a single agent pays for one system prompt and one set of tool definitions, and context accumulates inside one thread. On the right, three specialised agents each carry their own system prompt and tool definitions, so the fixed prefix is paid three times rather than once, and two handoff payloads travel between them. Context that would have stayed inside one accumulating thread is instead serialised, re-sent across a boundary, and starts accumulating again on the receiving side. The multi-agent arrangement therefore costs more than three times the single agent, which is why such a design should be costed before it is committed to.What splitting an agent in three actually buysONE AGENTprefix x1one accumulatingthread1 prefix, 0 handoffsTHREE AGENTSprefixplannerprefixresearcherprefixwriter3 prefixes, 2 handoffs re-sent as new tokensEach agent pays its own system prompt and tools, and context crosses boundaries as fresh input.Three agents cost more than three times one agent, not three times.Often worth it for reliability. Just cost it before you commit.
The handoffs are the part nobody budgets for. Context leaves one thread and restarts in another.

That is not an argument against multi-agent designs, which solve real problems in reliability and separation of concerns. It is an argument for costing them before committing. Model each agent's run separately, then add the handoff payloads as new tokens on the receiving agent, and compare the total against the single-agent version of the same task.

When the user owns the loop: chatbots and assistants

Everything above assumes you control the loop. You set the iteration cap, you decide what carries forward, you choose when to stop. In a chatbot or a long-running assistant that assumption breaks, because the user owns the loop and you cannot cap a human.

The token arithmetic is identical: every turn re-sends the accumulated conversation, so a twenty-turn support conversation is buying the same staircase as a twenty-step agent run. What changes is which controls remain available to you.

  • Summarise on a threshold, not on a cap. You cannot refuse a user's eleventh message, but you can decide that past turn eight the older history travels as a summary. The user notices nothing; the curve flattens.
  • Degrade gracefully instead of failing loudly. An agent that hits its ceiling should stop. A conversation that hits one should quietly narrow its memory, or offer a handoff, or start a fresh thread with carried context. Ending the session because it got expensive is a product decision, not an engineering one.
  • Watch cost per user, not cost per conversation. Conversational cost is heavily long-tailed: most sessions are two or three turns and a small group of engaged users generate the majority of the spend. An average conversation cost tells you almost nothing about the invoice.
  • Tier by value. If a free-tier user can open an unbounded session, your cost per user is unbounded too. Session length limits, memory depth and model tier are all fair things to vary by plan.

The distinction worth carrying: in an agent, the fix is to send fewer requests. In a conversation, you rarely get to send fewer, so the fix is to make each one carry less.

How we build agents against this at HorizonLux

HorizonLux is a software development company that specialises in AI, and agents are most of what we build, so this is not a literature review. It is the checklist our own scaffolding enforces.

  • The iteration cap and the circuit breaker are part of the agent scaffold, not a hardening task scheduled for later. An agent without them is not finished.
  • Context policy is decided before the first prompt is written. What gets summarised, what gets dropped after use, and how many turns stay verbatim. Retrofitting this means rewriting every prompt in the codebase.
  • The prompt is ordered for caching from the first commit. Stable content first, variable content last. This is free at the start and expensive later.
  • Cost per completed task is instrumented on day one, tagged by feature, and we watch the 95th percentile rather than the mean, because agent cost is long-tailed by nature.
  • Model choice comes last. Fixing the tier under a broken loop just makes the wrong thing cheaper.

None of it is exotic. It is the difference between an agent designed around its invoice and one that discovers the invoice in month three.

What to do this week

  • Find your longest run this month and ask whether it should have been allowed to run that long. Then set the cap.
  • Compare provider request counts to your own event counts. The gap is retries you are not seeing.
  • Print the input token count per step for one real run. If the last step is several times the first, carried context is your problem.
  • Turn on prompt caching for the system prompt, and check the TTL against how often the agent fires.
  • Then look at routing narrow steps to a small model, measured on completed tasks rather than tokens.

An agent is the most expensive shape a workload can take, and almost none of that expense is the model's price. It is the loop, the transcript and the retries, all three of which are yours to change. The wider sequence this fits into is in our guide to LLM cost optimization, and if you are still working out which part of your system is responsible, start with why is my AI bill so high.

Want an agent that holds up in production and on the invoice? We build iteration caps, circuit breakers, context policy and cost instrumentation as defaults. See how we approach AI agents, or tell us what your invoice looks like.

Frequently asked questions

How much do AI agents cost to run?

There is no useful per-month figure, because two teams on identical model pricing routinely differ more than tenfold on the same task. Cost is set by steps per run, the size of the fixed prefix, what travels between steps and how often steps fail. Express it as a multiple of a single completion instead: a twelve-step run on a frontier model typically lands around 20x to 30x.

Why do AI agents cost 19x to 50x a single API call?

Because context accumulates. Each step re-sends the system prompt, the tool definitions and every prior thought and tool result, so total input tokens grow with roughly the square of the step count rather than linearly. Retries compound it further, since a failed step re-sends the same large context and is billed again. The multiple is set by your step count, not by the model you chose.

What is the fastest way to cut agent costs?

Cap the iterations. It is usually a one-line change and it is the biggest lever, because the steps it removes are the most expensive ones in the run: the last steps carry the most context. Halving a twelve-step run removes far more than half the cost. Only after the cap is in place is it worth changing what travels between steps, caching the prefix, or switching model tiers.

Does prompt caching help with AI agent costs?

Yes, and agents are the strongest case for it. The system prompt and tool definitions are byte-identical on every step of every run, which makes them the most re-read span in the system, and cached tokens bill at roughly a tenth of standard input price. Unusually, the saving grows with step count. Check the cache TTL against how often your agent actually fires.

Are multi-agent systems more expensive?

Usually, and by more than the number of agents implies. Every agent carries its own system prompt and tool definitions, so the fixed cost is paid per agent rather than per system, and handoffs re-serialise context across boundaries where it arrives as fresh tokens and begins accumulating again. Cost each agent's run separately, then add the handoff payloads before committing to the design.

Should I use a cheaper model for agent steps?

For narrow steps such as tool selection, routing and extraction, yes, with escalation to a frontier model on low confidence or a schema failure. But apply it after the loop and context are fixed. In an agent, a weak model does not just answer worse, it fails, and a failure triggers a retry that re-sends the entire context. A model that fails 20% of the time can cost more than one that fails 2%.

Sources

Related articles

More on guides from the HorizonLux team.

Agents that survive their own invoice

Iteration caps, circuit breakers and context policy as defaults, not as hardening tasks scheduled for later.

Prefer email? [email protected]