What an agent actually
costs to run.
Every quote you have been given prices the build. Almost none of them price the running. This is the teardown: five cost layers, three real workflow shapes, and the retry tax that makes most estimates wrong by a factor of two and a half.
Everyone asks what it costs to build.
Almost every procurement conversation about AI agents opens the same way: what will it cost to build. It is a fair question and we answer it in a separate piece on AI agent development cost in India. But it is the smaller half of the decision. A build is a one-time number you negotiate once. Running the thing is a number that arrives every month for as long as the agent is alive, and it scales with exactly the success you were hoping for. Read the build-cost guide.
The trap is that run cost looks trivial when you first model it. You open the pricing page, multiply tokens by volume, and get a number small enough to wave through. That number is the floor, not the cost. In the workflows we have torn down, the token bill is roughly forty percent of what it actually costs to keep an agent in production, and the gap is not exotic: it is retries, evaluation, human review, and the ongoing maintenance of a system whose inputs keep changing underneath it.
This piece prices the running. Five layers, three workflow shapes with the arithmetic shown, and the failure-rate curve that decides whether your unit economics work at all.
Five layers, and only one is on the pricing page.
Run cost is not one line item. It is five, and they behave differently: some scale linearly with volume, some scale with failure rate, and one is almost fixed but never zero. Modelling only the first is how a project that looked profitable at pilot stops being profitable at scale.
Three workflows, priced to the unit.
Averages across all agents are useless, because a support agent and a document pipeline have almost nothing in common economically. What transfers is the shape of the arithmetic. Below are three workflow archetypes we see constantly, each priced to its natural unit, with the token-only figure most vendors quote set next to the all-in figure you will actually pay.
WhatsApp support agent
per resolved conversationDocument extraction pipeline
per documentInternal ops agent
per completed runThree different workflows, three different units, and the same multiple: the all-in cost lands between two and a half and three times the token bill. If you take one number from this piece, take that one. Budget 2.5× your modelled token cost and you will be approximately right before you have measured anything. The internal ops agent is the instructive case: it carries the highest maintenance share because it touches three systems, and integration surface is the single best predictor of what an agent will cost you in year two.
Run these numbers against your own volumes in the AI cost calculator.
Failure rate is a cost multiplier, not a quality metric.
Here is the part that breaks estimates. Retries do not add cost linearly, because a retry is rarely a clean rerun of one call. It replays accumulated context, it often triggers a fallback to a larger model, and in multi-step agents a single failed tool call can invalidate every step after it. The result is that cost climbs faster than failure rate, and the curve gets steep exactly where most unevaluated agents live.
This is the strongest financial argument for evaluation, and it is why the evaluation layer being the cheapest line in §02 is such a bad joke. Spending six percent of run cost on evals to move failure rate from twenty percent to five percent removes roughly a third of your total bill. The eval suite pays for itself several times over on cost alone, before you count the reputational cost of the failures your customers saw.
The mechanics of building that suite are in our step-by-step guide to LLM evaluation.
Buy until volume, then build.
- ·Priced per unit, so cost tracks usage exactly
- ·Maintenance and model upgrades are someone else's line item
- ·Ceiling on customisation, especially at the tool-calling layer
- ·Data residency and DPDP posture are inherited, not chosen
- ·Right answer below roughly 20,000 units a month
- ·Fixed engineering cost amortises over volume, so unit cost falls
- ·You own the maintenance layer, and it is 15% of run cost forever
- ·Full control of routing, model mix, and context economics
- ·Residency, audit trail, and guardrails are yours to specify
- ·Right answer above roughly 20,000 units a month, or when the workflow is the product
The crossover is arithmetic, not ideology. Take the platform's per-unit price, subtract your modelled all-in run cost from §03, and divide the build quote by the difference. That gives you the monthly volume at which building pays back. For most of the support and extraction workloads we scope, it lands somewhere between fifteen and thirty thousand units a month. Below it, buying is genuinely cheaper and you should. Above it, the platform margin you are paying every month exceeds what the engineering would have cost.
If you cannot see cost per unit, you cannot control it.
You cannot manage this from an invoice. The single highest-leverage instrumentation change is to tag every model call with the business unit it belongs to, a conversation, a document, a run, so that cost per unit becomes a metric you can chart rather than a number you reconstruct at month end. Once it exists, three things become visible: which workflows are quietly unprofitable, which prompt change moved cost, and how much of the bill is rework. Below is the shape of the report we run for clients on a weekly cadence.
Four cases where the agent is the wrong purchase.
The unit economics do not work for every workflow, and the honest version of this analysis has to include the cases where the answer is no. Four recur often enough to name.
The volume is too low
Below a few hundred units a month, the maintenance layer dominates everything and you are paying engineers to keep a system alive that a person could have run in a couple of hours a week. Automate it when the volume is real, not when the idea is exciting.
A deterministic system already solves it
If the task is rule-shaped, a workflow engine or a few hundred lines of ordinary code will do it at a fraction of the cost, with none of the retry tax and none of the evaluation burden. Language models are for the parts that are genuinely ambiguous.
The cost of being wrong exceeds the cost of the work
Where a single bad output creates legal, financial, or clinical exposure, the review gate has to be so heavy that the human is doing the job anyway. The agent then adds cost rather than removing it, and the honest framing is assistance rather than automation.
The underlying data is not ready
An agent over inconsistent, undocumented, or stale data inherits every one of those problems and charges you tokens to do it. The correct first investment is the data layer, which is slower, less exciting, and the only thing that makes the rest work.
We model the unit before we quote the build.
Every agent engagement we take on starts with the arithmetic in §03 applied to your actual volumes, your escalation rate, and your integration count, because a build quote that ignores run cost is a quote for the wrong thing. If the unit economics do not clear, we say so at that stage rather than after the invoice. The same cost instrumentation in §06 ships with the system, so cost per unit is a chart you own rather than a number you reconstruct.
→ See how we build and run AI agentsThe honest limits.
The figures here are modelled, not audited. They are built from current API pricing and loaded Indian salary costs against workflow shapes we see repeatedly, and they are meant to show you the structure of the calculation rather than to be quoted as your number. Your context length, escalation rate, and integration count will move the totals substantially, which is exactly why the method matters more than the arithmetic.
Model pricing is also falling, and falling unevenly. Per-token costs have dropped sharply for a given capability tier and will keep dropping, which shrinks layer one over time. What does not shrink is human review, maintenance, and the retry tax, and that is the real point of this teardown: the layers that are hardest to model are the ones that persist. A cost model built entirely on today's token price will be wrong in both directions within a year.
Finally, cost is not the whole decision. An agent that costs more per unit than the manual process can still be the correct investment if it removes a queue, holds quality at three in the morning, or lets a small team serve a market they could not otherwise reach. Price it honestly, then decide on the full picture rather than the unit cost alone.
Questions, answered.
01What does it actually cost to run an AI agent?+
Budget roughly two and a half times your modelled token cost. Across the three workflow shapes torn down in this piece, the all-in run cost landed between 2.4× and 2.6× the token bill, because tokens are only about forty percent of the total. The remaining sixty percent is retries and rework, evaluation, human review, and ongoing maintenance. In concrete terms, a WhatsApp support conversation modelled here costs about ₹11 all-in against a ₹4.20 token bill.
02How do I calculate cost per conversation for an AI agent?+
Sum five layers per unit rather than one. Take token cost for the full conversation including retrieved context on every turn, add the cost of failed attempts and retries, add your evaluation sampling, add human escalation priced as escalation rate multiplied by loaded cost per minute, and add amortised maintenance. Tag every model call with a conversation identifier so the number becomes a metric you chart weekly rather than one you reconstruct from an invoice at month end.
03Why is my LLM bill so much higher than estimated?+
Three causes account for most of it. Retrieved context is billed on every single turn, so a long system prompt plus RAG chunks can dominate a conversation that looked cheap per message. Retries are billed at full price and often escalate to a larger fallback model, so a twenty percent failure rate adds roughly seventy percent to cost rather than twenty. And runaway loops in multi-step agents produce a long tail, which is why you should watch p95 cost per unit rather than the mean.
04What is the retry tax?+
The retry tax is the disproportionate cost of failed attempts in agent systems. A retry is rarely a clean rerun of one call: it replays accumulated context, it often falls back to a more expensive model, and in multi-step agents one failed tool call can invalidate every subsequent step. Cost therefore climbs faster than failure rate. Moving from a twenty percent step failure rate to five percent removes roughly a third of total run cost, which makes an evaluation suite pay for itself on cost grounds alone.
05Is it cheaper to build an AI agent or buy a platform?+
Buy below roughly twenty thousand units a month, build above it. The crossover is arithmetic: take the platform's per-unit price, subtract your modelled all-in run cost, and divide the build quote by that difference to get the monthly volume at which building pays back. For most support and document extraction workloads we scope, that lands between fifteen and thirty thousand units a month. Building also makes sense below that threshold when the workflow is the product itself, or when data residency requirements rule the platform out.
06How much does it cost to develop an AI agent in India?+
That is the build question rather than the run question, and we cover it separately in our guide to AI agent development cost in India, which walks through pilot budgets and production rollout drivers. The two numbers should always be quoted together. A build quote that does not come with a modelled run cost is pricing the smaller half of the decision, and it is the half that stops billing you once it is delivered.
07How do we reduce AI agent running cost without hurting quality?+
In order of impact: cut the failure rate first, because it is the steepest term in the model and evaluation is the cheapest layer you can buy. Then fix context economics, since retrieved context billed on every turn is usually the largest single waste, and tighter retrieval beats a cheaper model. Then route by difficulty, sending easy turns to a small model and escalating only where it is warranted. Cache aggressively on stable prefixes. Changing model tier across the board is the crudest lever and usually the one teams reach for first.
08When is an AI agent not worth the money?+
Four cases. When monthly volume is in the low hundreds, so maintenance dominates every other layer. When the task is genuinely rule-shaped and a workflow engine or ordinary code solves it without any retry tax. When being wrong carries legal, financial, or clinical exposure heavy enough that the review gate means a human is doing the work anyway. And when the underlying data is inconsistent or stale, in which case the data layer is the correct first investment and the agent will only charge you tokens to inherit the problem.
Model the unit before you sign the build.
Bring your volumes, your escalation rate, and the systems it has to touch. In one conversation we can usually tell you what the unit will cost you and whether the economics clear at all.
Start a conversation →