What does an AI agent actually cost? Measure for a month instead of guessing

The bill from your AI provider is one of the few invoices almost nobody has a substantiated story to go with. There's an amount, the amount matches usage, and beyond that it's a black box. Ask a team which part of their system eats the lion's share and you rarely get an answer with a number in it. Usually you get a hunch.

The problem: a monthly total is not a measurement

A monthly total is a sum, and a sum hides exactly what you're looking for. If you run twenty workflows and one of them costs four times as much per run as the rest, that doesn't show up in the total. All you see is that the total is higher than last month. Then you go and do something — downgrade a model, set a limit, switch off a feature — without knowing whether you're turning the right dial.

Worse still: the reflex is almost always to steer on what's visible. Make answers shorter. Pick a cheaper model for everything. Run less often. Those are measures you come up with when you have no data, and they rarely address the actual cause. In agent work that cause sits almost always on the input side, and that's precisely the part you don't see if you only look at the output.

An average across your entire monthly bill hides exactly the outlier you want to find.

What exactly to log — per call

The solution isn't complicated. You don't need an observability platform and you don't need a dashboard suite. You need a table in which every AI call becomes one row. We keep that in our own cost register — a SQLite database, nothing more — and it currently holds over 3,300 calls. That's enough to see patterns you would never have noticed in a monthly total.

These are the fields recorded per call. It's a list you can adopt today:

• Provider — which vendor handled the call.
• Model — which exact model, not the family. "The big model" is not a measurement.
• Tokens in — the number of input tokens. This is the field that explains the most.
• Tokens out — the number of output tokens.
• Cost in euros — calculated at the moment of the call, not reconstructed afterwards.
• Latency — how long the call took. Cost and slowness go together more often than you'd think.
• Correlation id — the field that ties individual calls back to one workflow or one task.

That last field is the most important one and the one most often forgotten. Without a correlation id you have a list of expensive calls but no idea which process they belong to. With a correlation id you can ask questions like: what does one full run of this workflow cost, from first call to last? That's the question a decision follows from. What such a chain looks like in practice is shown in the workflow showcase.

Why input tokens are the real cost driver with agents

This is where the most valuable observation sits. In agent work the number of input tokens dominates the bill. A single agent call can contain more than 100,000 input tokens, against a few thousand output tokens. That ratio isn't an exception — with agents it's the normal case.

That makes sense once you look at where that input comes from. An agent call drags three things along. First the context: system instructions, tool descriptions, rules, examples. Second the history: everything already said and done in this session, including the output of earlier tools. Third the retrieved documents: whatever the retrieval layer pulls in alongside. All three grow the longer the agent works. Meanwhile the output stays roughly the same length: an answer, a decision, a next action.

The consequence: steering on output length means turning the wrong dial. You can instruct your agent to answer more briefly and touch a fraction of the cost, while the part that determines the bill stays untouched. Only once you see per call how much input goes in does it become clear where to intervene.

API versus subscription: how to make that comparison fair

The second question that always comes back: is a fixed subscription cheaper than API usage? There's no general answer to that, because it depends entirely on your own usage pattern. But you can measure it instead of debating it.

So per call we also record what that same call would have cost under a fixed subscription. That means the register holds two amounts side by side: the actual API cost and the subscription equivalent. At the end of a period you can then put two real totals next to each other instead of comparing a real amount with an estimate.

Why this makes such a difference: a subscription is attractive with a high, stable usage pattern and unattractive with an erratic or low one. Which of the two you have is something you only know once you have a month of actual calls on record. A comparison based on an average day is misleading, because it's precisely the peaks that determine whether you fall inside or outside a subscription limit.

Three dials that do work

Once you measure per call, three interventions become visible that genuinely sit on the input side.

1. Prune the context

Look at what structurally travels along in every call and ask, for each element, whether it really belongs there. Usually part of the history turns out to be irrelevant to the current step, and retrieved documents turn out to be loaded in more broadly than needed. Pruning isn't a one-off action but a design choice: decide explicitly what has to go along per step instead of passing everything through by default. The correlation id helps you here, because it lets you see which step in a chain drags the most along.

2. A smaller model for the preparatory work

Not every step in an agent chain calls for the heaviest model. Classifying, summarizing, filtering, deciding whether a document is relevant — those are tasks a smaller model handles perfectly well. Deploy the big model for the step where reasoning genuinely counts. Because you log the model per call, you can check afterwards whether quality did indeed stay the same and didn't quietly slip.

3. Caching

The part of your input that's identical on every call — system instructions, tool descriptions, fixed rules — doesn't have to be treated as fresh input every single time. Caching targets exactly the part that with agents is the largest and the most repeated. That makes it the most direct intervention on the item that dominates the bill.

Conclusion: measuring is the cheapest optimization

Logging per call feels like overhead. It's maintaining a table that does nothing, adds no functionality and makes no user happy. But it's the one intervention that makes all other interventions possible, and it costs you an afternoon's work.

Without per-call logging you don't know which workflow is costing you money. You only know what the total is, and on the basis of a total you can't make a single targeted decision — only blunt ones. Blunt decisions on AI costs have the unpleasant property that they usually hit quality too: you switch something off, you move to a smaller model for everything, you limit usage. With per-call data you can instead tackle the one expensive component and leave the rest alone.

So don't start by optimizing. Start by logging, let it run for a month, and only then take a look. The outlier you're after is almost certainly in there — it was just invisible in the average. If you want to know how we set this up inside existing systems, take a look at our services.