How much a team spends on AI agents and how to measure it

In the previous post, "Tokens al mando", I described how we moved from intuition to measurement per task and per agent. Once teams take that step, a question comes up that I have been asked several times: how much are we really spending, and on what?

It is not a trivial question. When AI agents go from being an experiment to being part of the daily workflow, cost stops being a marginal line item and starts competing with other engineering budget lines. And as with any expense that grows fast, the first thing needed is not to cut it: it is to see it clearly.

I share how I think about this problem, focusing on three concrete things: how to choose the model per task, what to log when a task finishes, and what to look at on a cost dashboard so it actually changes decisions.

Choose the model by task, not by habit

One of the most common mistakes I have seen is using the same model for everything. It is understandable: once a team finds a model that "works well", the temptation is to leave it fixed across every agent and flow. The problem is that this lumps very different tasks under the same cost, and that is where spending becomes invisible.

What works for me is thinking in at least three model tiers according to the real demands of the task:

• Economy: for repetitive, low-risk tasks where the tolerable margin of error is high. Classifying text, summarizing tickets, extracting structured data from a known format. The goal here is volume, not sophistication.
• Standard: the middle ground for most of an agent's daily work: moderate reasoning, code generation over known contexts, replies to users with limited context.
• High: reserved for tasks where the cost of a mistake is high or where multi-step reasoning is essential: decisions that affect a customer, complex planning, code in critical systems.

The key is not "the best model available" but the right model for that specific task. An agent that uses the high tier to classify emails spends budget on something the economy tier solves just as well. And the other way around: an economy-tier agent trying to solve a problem that needs deep reasoning will fail, retry, and end up costing more in tokens (and time) than if it had used the right model from the start.

This "which model for which task" decision should not be a fixed, forgotten setting. It is worth reviewing with data, and that is where the second point comes in.

Log input and output tokens when each task closes

If in "Tokens al mando" we talked about measuring per task and per agent, the next level of detail is logging input tokens and output tokens separately when each task closes.

Why separate them? Because they have different cost dynamics and say different things about the agent's behavior:

• Many input tokens usually indicate that the context given to the agent is too large: full history when a summary would do, entire documents when a relevant fragment is enough.
• Many output tokens may indicate that the model is being verbose, repeating itself, or that the task itself requires generating a lot of content (which can be legitimate, but is worth knowing).

Logging this when each task closes —not as an aggregate average at the end of the month— later lets you cross-reference the data with the model used, the effort applied, and the result obtained. On this site, every task and every cycle records model, effort, and tokens, and that data shows up in a cost view. It is not a report assembled by hand afterwards: it is part of the natural close of each piece of agent work.

That granularity is what turns a cost dashboard into a decision tool instead of an accounting curiosity.

What to look at on a cost dashboard and which decisions it changes

Having the numbers is not worth much if the dashboard becomes one big number at the end of the month that nobody can explain. What I look for when reviewing an agent cost dashboard is answers to concrete questions, not just "how much did we spend":

Which tasks concentrate the spending? If a large share of the cost sits in one type of task, that is the first candidate to check whether the chosen model is right or whether the flow can be optimized before touching anything else.

Does the effort applied match the real complexity? When the dashboard shows effort and model per task, mismatches are easier to spot: simple tasks solved with expensive models, or complex tasks solved with minimal effort (which probably explains retries or low-quality results).

Are there agents with disproportionate input tokens? It is almost always a sign that the context passed to them can be trimmed without losing result quality.

Is the cost per task going up or down over time? A sustained trend in either direction is more useful than a single number. If it goes up, you need to understand whether tasks became more complex or the flow degraded. If it goes down, it is worth understanding which change caused it so it can be replicated in other agents.

These four questions, answered with real data on tokens, model, and effort per task, are the ones that change decisions in practice: when to move down a model tier, when it is worth summarizing or trimming context, and where to pay attention before spending becomes a budget problem instead of an efficiency lever.

What I took away

• Measuring tokens per task and per agent gets a team out of intuition; the real value appears when that measurement turns into decisions.
• Choosing the model by task, and reviewing it with data, avoids both invisible spending and costly retries.
• Logging input and output tokens separately, when each task closes, gives more information than a monthly average.
• A useful dashboard answers concrete questions: where spending concentrates, whether effort matches complexity, and how cost per task evolves.

If you are working on something similar or your team is evaluating how to adopt and measure AI agents, I would like to exchange experiences: you can write to me on LinkedIn. And if you want to know more about how I work, I describe it at https://estebanburgos.com.ar/about-me.