AI agent costs: calculate a realistic usage budget
Understand and price the variable running costs of an AI agent: model, tools, storage, human review and retries, with a full calculation at three volumes.
An AI agent does not cost only at purchase: it is the monthly operation that weighs. Between model billing per token, tool calls, storage, human review and retries after failures, the real cost varies with volumes, models and review work. This article breaks down each variable line item, then provides a complete, clearly fictitious calculation at three activity levels, with caps and alerts to keep spending under control.
Why the quoted price tells you almost nothing
When you evaluate an ai assistant cost, the figures you are given usually cover the build: initial development, configuration, go-live. But an agent lives every day, and its consumption follows your business activity. A quiet month and a peak month are nothing alike on the invoice.
Another article covers the total price of an agent project, meaning the upfront investment and its components. Here we deliberately stay on ongoing operation: what each execution costs, month after month, and how to anticipate variations. The two readings complement each other, but neither replaces the other.
This approach fits the broader evaluation framework described in AI agent costs: the full picture, which we do not repeat here. The goal is to make you able to price your own usage scenario yourself, before even choosing a vendor.
The five variable cost lines
The first line is the model itself. Most APIs bill input and output separately, in tokens, at different rates. An agent that reads a lot of context and produces little text does not have the same profile as a writing agent. This line therefore depends on two parameters: tokens per execution and number of executions.
The second line, often underestimated, covers tool calls: search, database reads, sending notifications, connecting to third-party services. Each call can be billed, either directly or through the connected service. An agent that queries five tools per task costs more than one that queries a single tool.
The third line is storage: conversation histories, indexed documents, execution logs. It grows over time even when activity stagnates, which makes it a sneaky line. The fourth is human review: if a human validates sensitive outputs, their time has a price, and its share must be measured rather than assumed. The fifth covers retries: every execution that fails and must be run again consumes tokens and tool calls once more.
The model line: tokens, context and caching
Estimating model cost takes three questions. How many tokens go into each execution, including conversation history and supplied documents? How many tokens come out? And what are the input and output rates of the chosen model?
Watch out for context accumulation. A conversational agent that resends the entire history at every turn pays more and more as the exchange grows. Limiting the context window, summarizing older exchanges and avoiding re-injecting whole documents are the three most effective levers. Context caching, when the vendor offers it, reduces the cost of repeated parts, but it does not remove output billing.
One last point: models are priced differently by capability. An advanced reasoning model can cost several times more than a standard model for the same task. Choosing the least capable model that does the job is an economic decision before being a technical one.
Tools, storage and human review
Tools are priced in two ways: direct cost per call when the tool's API bills by usage, and indirect cost when the tool triggers billing at a third party. For instance, sending a message on WhatsApp Business Platform follows Meta's per-delivered-message pricing, by category and market, and not all messages are charged: the 24-hour service window, reopened by a user message, changes the picture. The official platform pricing page should be checked directly, as it varies by market.
Storage is reasoned about as a monthly cost per gigabyte, but above all as a retention policy. Keeping twelve months of histories when one month is enough multiplies the bill by twelve with no added value. Defining a retention period, then purging automatically, is a simple control.
Human review is the most expensive line in hours, but the least automatable. The right reflex is to target it: validating everything costs too much, validating nothing exposes you to visible errors. Random sampling plus blocking rules on sensitive cases is a good compromise. Note that if your agent handles email, the Gmail gmail.compose or gmail.modify scopes can also allow sending; restricting behavior to drafts therefore requires application-level controls, because a scope label is not a Gmail permission boundary. Reviewing drafts before sending then becomes a cost line in its own right, justified by risk control.
Retries: the silent multiplier
No agent succeeds one hundred percent of the time. Network timeout, unavailable tool, malformed response: every retried failure consumes tokens and tool calls again. If ten percent of your executions fail once before succeeding, your model and tool lines increase by ten percent, mechanically.
Two precautions limit this multiplier. The first is to cap the number of attempts, typically two or three, to avoid costly loops. The second is to make retries idempotent, meaning a rerun must not create duplicates. Fine-grained handling of these mechanisms is detailed in workflow automation: manage retries and duplicates, and it has a direct, measurable effect on the invoice.
Full worked example: a fictitious scenario
Take a fictitious quote-preparation agent. Rates are entirely fictitious, named for the exercise: model A at €3 per million input tokens and €9 per million output tokens; tools at €0.02 per call; storage at €0.02 per gigabyte per month; human review at €0.50 per reviewed file; a 5% retry rate on the model and tool lines. Each execution consumes 2,000 input tokens, 600 output tokens, and triggers two tool calls. Twenty percent of executions go through human review.
At low volume, 500 executions per month: input 1 million tokens (€3.00), output 0.3 million (€2.70), tools 1,000 calls (€20.00), storage 1 GB (€0.02), review 100 files (€50.00), retries 5% of €25.70, i.e. €1.29. Total: €77.01.
At medium volume, 5,000 executions: input 10 million (€30.00), output 3 million (€27.00), tools 10,000 calls (€200.00), storage 3 GB (€0.06), review 1,000 files (€500.00), retries 5% of €257.00, i.e. €12.85. Total: €769.91.
At peak, 20,000 executions: input 40 million (€120.00), output 12 million (€108.00), tools 40,000 calls (€800.00), storage 5 GB (€0.10), review 4,000 files (€2,000.00), retries 5% of €1,028.00, i.e. €51.40. Total: €3,079.50.
| Line item | Low volume (500) | Medium volume (5,000) | Peak (20,000) |
|---|---|---|---|
| Model input | €3.00 | €30.00 | €120.00 |
| Model output | €2.70 | €27.00 | €108.00 |
| Tools | €20.00 | €200.00 | €800.00 |
| Storage | €0.02 | €0.06 | €0.10 |
| Human review | €50.00 | €500.00 | €2,000.00 |
| Retries (5%) | €1.29 | €12.85 | €51.40 |
| Monthly total | €77.01 | €769.91 | €3,079.50 |
The key takeaway: human review dominates at every volume, and the model line stays modest. Cutting variable cost therefore does not start with a cheaper model, but with better-targeted review and fewer tool calls. This finding is specific to this scenario; a long-form writing agent would reverse the proportions.
Building a budget and spending caps
An operating budget is built in three layers. The first is a reference monthly estimate, from the calculation above applied to your real volume. The second is a hard cap: a spending limit configured at the vendor or in your application, beyond which the agent pauses rather than keeps billing. The third is a peak reserve, arbitrarily set here at fifty percent of the reference month, released by human decision and not automatically.
Alerts complete the setup. A warning threshold at seventy percent of the cap, notified to a named person, leaves time to react. An anomaly alert, triggered when a day's consumption exceeds three times the trailing thirty-day average, catches fast drifts: a retry loop, an agent triggered by mistake, a ballooning context.
Classic mistakes to avoid: confusing cap and alert, the first blocks, the second informs; forgetting that storage does not follow call caps; and setting a cap so low that the agent stops mid peak day, which turns a saving into a service outage.
Procedure: estimate your budget in one hour
Here is an actionable procedure, to run in a spreadsheet.
- Count the expected executions per month, from your current volume for the targeted task, not an optimistic projection.
- Measure tokens per execution: send ten representative tasks to a model and read the input and output counters provided by the API.
- List tool calls per execution and attach each one's cost, direct or indirect, including outgoing messages to billed channels.
- Price human review: minutes of checking per file, times the person's fully loaded hourly cost, times the share of files reviewed.
- Add expected monthly storage and your retention policy.
- Apply your estimated retry rate, comparing several assumptions if you have no data.
- Compute the total, then set the cap, the peak reserve and two alert thresholds.
- Recompute every quarter with real consumption data.
This procedure also serves to challenge proposals: if a vendor cannot break down these lines, the comparison stays blind. The framework in comparing AI agent agency proposals helps you structure that questioning.
Responsibilities: who pays what, and who decides
Transport connection, vendor authorization and proof of operation are three different things, and costs follow that distinction. You may pay transport on one side, the tool vendor on the other, and carry yourself the responsibility of proving an operation actually happened. In the MCP protocol, which structures the exchange of tools and context between your application and tool servers, nothing chooses business rules or permissions on your behalf: the MCP architecture documentation describes it as an exchange framework, without replacing your application's access decisions and business controls. Costs and permission decisions remain on your side.
Concretely, appoint a budget owner, even in a small organization. That person receives alerts, arbitrates the peak reserve and approves any cap increase. Without a named owner, AI agent cost drifts are discovered on the invoice, after the fact.
Finally, if your agent touches personal data, minimization and retention limits reduce both risk and storage. The core principles recalled by the CNIL offer a thinking framework; these are design recommendations, not a compliance opinion.
To isolate message-review costs, measure the time actually saved by email automation, including review and corrections in both compared scenarios.
If you would like to frame a realistic operating budget for your own usage, you can define a mission with Edeverse.
Frequently asked questions
Is the model line always the biggest one?
No. In our fictitious scenario, human review dominates by far. For a writing agent producing long texts, the model can become the top line. The only way to know is to measure real tokens on representative tasks.
How do I set a cap without breaking the service?
Start from the reference month, add the peak reserve, then check the history of your busiest days. The cap must cover the worst known day times the number of working days, with margin. Test it in simulation before enforcing it.
Should retries be budgeted from day one?
Yes, even without history. The five percent used here serves the fictitious calculation only. Also test an unfavorable assumption: the frequency and cost of retries depend on your task, your tools and the severity of failures.
Does storage really deserve a budget line?
At low volume it is negligible, as the table shows. But it grows mechanically over time and does not follow your call caps. Without a retention policy, it becomes the only line that rises even when activity falls.
Should a human validate everything?
It depends on the consequences of an error. Systematic validation remains necessary for some actions; on less sensitive results, targeted review can be considered after qualification. In our example, dropping from one hundred percent to twenty percent of reviewed files would cut the peak monthly total by more than half.