AI agent cost control: measure and cap token usage

Your customer service agent has been running for six weeks, the team is happy, response times are shorter. Then the invoice from the model provider arrives: instead of the budgeted 90 euros, the bill shows 1,400 euros. No outage, no error in the log, no red alert. The agent simply did more work than planned, in places nobody was watching.

That is exactly where the problem sits. With a chat window you know the cost, because one click is one request. With an agent, an operation is not a call but a loop of calls, tools and new decisions. The costs arise where nobody is looking.

In this article you will learn why agent costs behave differently from chat costs, what an operation really costs across four cost blocks, how to make cost per operation measurable, and which four levers will pull a cap into place within a week, one that holds in day to day operations as well.

---

Table of contents

1. Why agent costs spiral out of control
2. What an agent really costs
3. Making cost per operation visible
4. Four levers that limit costs
5. A cost cap in one week
6. Conclusion

---

Why agent costs spiral out of control

The difference between a chat window and an agent is not a detail, it is the core of the cost problem. In a chat, the input is as large as your question and the output as large as the answer. With an agent, the system itself decides how many steps it needs: it reads data, calls tools, evaluates intermediate results, corrects itself and occasionally starts over from the beginning. Each of those steps is its own model call with its own token consumption. Anthropic put a public number on this effect in June 2025: agents typically consume about four times as many tokens as a chat interaction, multi-agent systems about fifteen times as many. The fourfold amount is not an outlier, it is the normal case, and it does not show up in any statistic that only counts requests.

The most common cause of runaway costs is therefore not an expensive model but a loop without an end. We see three patterns in almost every project we take over. First, the retry: a tool returns an error message, the agent tries again, then a third time, and the three failed attempts cost more than the original job. Second, the growing context: every stage is sent the entire history along with it, so input token consumption grows disproportionately with each step. Third, model choice without differentiation: the same large model decides whether a form field is empty, writes the customer reply and checks the invoice at the same time.

That this topic is gaining relevance right now was shown by a report from heise online on 21 September 2026. At its .conf customer conference in Denver, Splunk described four developments that currently shape the operation of AI systems: inference has replaced training as the dominant workload, agents are becoming standalone applications and digital employees, tokens have in the company’s assessment taken on the character of a currency, and control is becoming the real moat. In response, Splunk is bringing Agent Observability features to market that let you observe an agent’s behavior not only at runtime and after the fact, but also express the costs in euros through a token economy. The tool is also meant to suggest equivalent but cheaper models. When a monitoring vendor of that size makes cost control a core feature, the question is no longer whether you should measure your agent costs, but only how you start this week.

A second point from the same report is worth noting: Splunk points out that some of these security features only prove themselves in hindsight. A damage pattern is often recognized only after the incident. The same pattern applies to costs. The most expensive month is the one in which nobody wrote anything down, and afterwards you can no longer reconstruct which operation consumed what amount. You do not need an enterprise platform to prevent that. You need one number per operation, and that can be collected with the tools you already have.

What an agent really costs

Anyone talking about agent costs almost always means the model bill. That is the smallest part. In practice the effort consists of four blocks, all of which should be measured, because they behave differently.

Block 1: Model tokens. The consumption for all calls of an operation, meaning the prompt, intermediate steps, tool descriptions and the finished answer. This is the only block that varies when a model fails and the agent runs into a loop.

Block 2: Tools and infrastructure. The n8n instance or the server the workflow runs on, a vector database or a knowledge store, paid third-party interfaces, for example for address validation, shipping data or payment data. These items are largely fixed and are therefore rarely converted to a per operation basis.

Block 3: Operations and monitoring. The time spent on logs, checks, updates and evaluating the quality measurement. This is usually a fixed block too, but one that many projects underestimate, because it never appears in a quote.

Block 4: Human rework. Every escalated operation costs working time. This is the block that comes up least often in conversations and hits the bill the hardest.

A worked example with disclosed assumptions makes the difference clear. Assume 40 operations per day, 60,000 input tokens and 6,000 output tokens per operation including the agent loop, and prices of 1.50 euros per million input tokens and 6.00 euros per million output tokens for a mid-range model.

• Input: 40 operations times 60,000 tokens, that is 2.4 million tokens per day, which comes to 3.60 euros.
• Output: 40 operations times 6,000 tokens, that is 240,000 tokens per day, which comes to 1.44 euros.
• Total model cost: 5.04 euros per day, or around 105.84 euros per month across 21 working days.

The same 40 operations as simple chat requests (factor four from the Anthropic figure quoted above) cost about 1.26 euros per day, so 26.46 euros per month. As a multi-agent system with parallel sub-agents (factor fifteen) it is 75.60 euros per day and around 1,587.60 euros per month. These three figures alone explain why the topic deserves attention: the architecture, not the model, decides the factor of 15.

Now comes the block that turns the calculation around. Assume an escalation rate of 8 percent, six minutes of rework per case and a fully loaded cost of 45 euros per hour. That is 3.2 escalations per day, so 14.40 euros of rework every day. Rework is therefore almost three times as expensive as the entire model bill. Anyone who optimizes only model costs is working on the smaller lever.

For comparison, the starting point: the same 40 operations done by hand, eight minutes per operation, cost 240 euros per day. With model costs and rework combined, the agent sits at 19.44 euros, a saving of 220.56 euros per day or around 4,632 euros per month. So the agent is economical, but only as long as the escalation rate does not tip. If it rises from 8 to 20 percent, rework alone grows to 36 euros per day and the saving melts away noticeably. That makes the agent less a technology project than a question of the rate.

Practical tip: Do not calculate your agents in tokens, but in cost per successful operation. This one number makes outages, model changes and expansion plans comparable, and it is the only metric that a manager understands without an explanation.

Making cost per operation visible

Without measurement there is no cap. The good news: almost all the data you need is already produced in operation, it is just not being recorded. For every operation, eight values belong in a single row: operation ID, purpose, model used, input tokens, output tokens, number of tool calls, result (successful or escalated) and cost in euros. A timestamp is also worth adding, so you can spot daily and weekly fluctuations.

Most model providers return the token figures directly with the response, and in n8n you will find them in the response object under the usage field. The number of tool calls and the number of loop iterations are in the execution log, in n8n in the execution view. Do not write cost into the database, always calculate it from tokens and the price currently on file. A hard-coded euro amount goes stale with the next model change, a formula does not.

These raw data then produce four reports that carry the operation:

1. Cost per successful operation. The denominator counts only the cases that were completed without a human. This number rises when quality drops and falls when a lever takes effect. It is your lead metric.
2. Share of escalations. It links cost and quality, because every escalated operation costs working time. We described one way to measure response quality in the article on silent failures in production, and that is exactly where the cost figure fits in as the second number.
3. Tokens per operation as a distribution, not an average. The average hides the outliers. The five most expensive operations of a week almost always show the cause: an endless loop, a 200-page document, a tool that repeatedly returns errors.
4. Cost per type of operation. Complaints, new enquiries, order status: the types of operation differ considerably. Some pay off, some should run entirely without a model.

A table in a database or a spreadsheet is enough for storage. For an agent that takes over customer service, you will find matching patterns in our guide to customer service automation with n8n, including the question of which operations should be automated at all. And if you want to compare across several automations, the seven AI automations for small and mid-sized businesses offer enough candidates for a clean cross-comparison of cost per operation.

Four levers that limit costs

Measuring alone does not lower costs. It only makes them visible. What actually keeps the bill small are four levers you should set in every agent, regardless of the platform.

Lever 1: Loop limit. Define a hard upper bound on steps, say eight tool calls per operation. Once it is reached, the agent does not keep trying, it escalates. That prevents exactly the pattern that blows up bills: an agent running three times against the same error message. A loop limit is the cheapest insurance available in agent operations.

Lever 2: Model per step. Not every step needs the largest model. Classification, field extraction and format checking are handled by a small, fast model at a fraction of the cost. The large model is used only where text is written or trade-offs are weighed. With its Agent Observability, Splunk offers suggestions for equivalent but cheaper models precisely for this purpose, which shows how much saving potential lies in operations simply in the mapping of task to model.

Lever 3: Context cap. Do not send the entire conversation history, only the last messages and the sections from the knowledge store that are actually relevant. Two techniques help immediately: write intermediate results to files or database fields instead of into the history, and summarize long histories instead of appending them. Anyone who lets the history grow without limit pays the same rate several times over, once more with every step.

Lever 4: Budget, permissions and identity. Set a daily budget and a monthly budget, with an alert at 80 percent consumption. Assign roles instead of full access: the agent may read what it needs and write what it is entitled to. And give every agent its own identity instead of an employee’s credentials. Why that last point is not a detail was shown by a case from 20 September 2026, which heise online reported on 22 September 2026. Amazon blocked Meta’s personal AI agent Muse from its shop and showed users a popup stating that further access by an unauthorized AI agent violated its terms of service. Amazon justifies the move by saying the agent does not identify itself while browsing and captures login data, which Meta disputes. Regardless of who is right in that dispute, the lesson for every business is the same: an agent that does not identify itself and has no defined rights loses access. Payment networks are currently working on standards for the identification of agents, and the same standard will soon apply to internal systems as well.

On top of that there is a security dimension that heise online reported on 21 September 2026: attackers can gain access through a critical vulnerability in several widely used coding agents and command line tools. Every agent is a doorway into your systems, and an agent with full access to all tools is, when in doubt, the most convenient way in. A limited tool scope is therefore both cost protection and attack surface protection.

A compact building block for the budget lever, usable directly as a code node in n8n:

// n8n Code node: abort the run when the cost or step limit is reached
const item = $input.first().json;

// Prices per 1 million tokens, maintain centrally and not in the prompt
const PRICE_IN = 1.5;
const PRICE_OUT = 6.0;

const MAX_STEPS = 8;
const MAX_COST_PER_RUN = 0.35;
const DAILY_BUDGET = 12.0;

const steps = Number(item.steps || 1);
const tokensIn = Number(item.usage?.input_tokens || 0);
const tokensOut = Number(item.usage?.output_tokens || 0);

const cost =
  (tokensIn / 1000000) * PRICE_IN + (tokensOut / 1000000) * PRICE_OUT;

const todayCost = Number(item.budget?.spentToday || 0) + cost;

const reasons = [];
if (steps > MAX_STEPS) reasons.push("Loop limit reached (" + steps + ")");
if (cost > MAX_COST_PER_RUN) reasons.push("Cost per run exceeded");
if (todayCost > DAILY_BUDGET) reasons.push("Daily budget exhausted");

const escalate = reasons.length > 0;

// On escalation: hand the run over to a human, do not let it continue
return [
  {
    json: {
      ...item,
      cost: Number(cost.toFixed(4)),
      spentToday: Number(todayCost.toFixed(4)),
      escalate,
      escalateReason: reasons.join("; "),
    },
  },
];

Practical tip: Set the tool scope narrower than feels right. An agent that cannot reach payroll cannot cause costs there and cannot lose data there either. A permission can be extended in five minutes, an incident takes weeks.

A cost cap in one week

You do not need a platform or a budget for this. Five steps spread across one working week take an agent from flying blind to solid numbers.

Step 1: Record cost per operation, for seven days. Take the agent with the highest consumption. For every operation, write the token figures from the response, the number of tool calls and the result into a table. Nothing more. This one week provides the basis for everything that follows.

Step 2: Look for outliers, not averages. Open the five most expensive operations. In almost every case you will find a loop, an oversized document or a tool with errors. Fix that cause first. Experience shows the biggest single effect on the monthly bill lies there.

Step 3: Set two levers. Start with the loop limit and the model per step. Neither changes quality for normal operations, but both reduce the outliers at the top end. After three days, check cost per successful operation and the escalation rate.

Step 4: A cap with an alert. Set a daily budget and have yourself notified at 80 percent consumption, not only when it is exceeded. An alert that arrives before the limit allows a decision. An alert afterwards only provides an explanation.

Step 5: One number in the weekly report. Add cost per successful operation and the escalation rate to your existing report. Once this number is visible, every discussion about model changes, prompt edits and expansion becomes a discussion about impact instead of a feeling.

Conclusion

The model bill is the smallest cost block with AI agents, not the largest. The decisive items arise in the loop, in the rework and in the tool calls that nobody counts. At the same time, the idea that an agent burns tokens uncontrollably rests on an avoidable cause: missing levers. A loop limit, model per step, context cap and a budget with permissions and identity can all be built in together in a single day.

The gain from this work is not only the lower bill. Anyone who knows cost per operation can justify at any time why an agent is economical, and can counter-steer when the escalation rate rises, before the saving tips over. It is precisely this evidence that distinguishes an automation project that stays from one that is shut down after the first expensive month, especially in small and mid-sized businesses.

The market is signaling the same direction. Observers such as Splunk declare control to be the moat, payment networks are working on standards for identifying agents, and platforms decide which agents get access. Visibility and limitation are becoming a precondition for being allowed to take part at all. How many of your automated operations could you put a euro figure on today?

About MadeByBrain: We build AI automation for small and mid-sized businesses – our own AI agents, n8n workflows and GEO strategies, live in operation. From the first idea to productive automation.

Book a free strategy call →