Metering: knowing what the AI actually cost

What is recorded, per run

Every agent evaluation records input tokens, output tokens, the model used, the wall-clock duration and the outcome — findings produced, or none.

Each of those is attributed three ways: to an agent, so you can see which evaluations are expensive; to an object or scope, so you can see what the money was spent looking at; and to a trigger, so a scheduled run is distinguishable from an event-driven one and from a person clicking a button.

That third attribution is the one most systems omit and the one that explains the most. An agent whose cost tripled has usually not changed — something upstream started emitting more events, and only the trigger breakdown makes that visible rather than mysterious.

The three questions it answers

Metering exists to answer specific questions rather than to produce a dashboard. Three come up in every deployment, and all three are unanswerable from an invoice.

• What are we spending this on? Broken down by agent and by scope, which is what turns *our AI bill went up* into *the supplier agent is now evaluating four thousand items instead of four hundred because somebody widened its scope*.
• Is it worth it? Cost per agent set against findings accepted, rejected and ignored. An agent costing meaningful money whose findings are dismissed nine times out of ten is a configuration problem with a number attached to it.
• What will next month look like? Run rate by trigger type, which is the only basis for a forecast. Scheduled evaluation is predictable; event-driven evaluation scales with how much your organisation is changing, and that distinction is the whole forecast.

The failure it prevents

An organisation enables agents across its whole tenant because the pilot went well. The pilot covered one product line. The full deployment covers eleven, plus the archive.

The first month's cost is roughly nine times the projection. Nobody can say which part is legitimate — some of it certainly is — so the response is the only one available without data: turn everything off and re-evaluate next quarter.

The capability was not the problem and never got assessed on its merits. Per-run attribution would have shown within a day that eighty percent of the spend was one agent re-evaluating archived items that nobody was going to change, which is a scope fix rather than a reason to abandon the whole thing.

How it meets the rest of the product

Budgets consume metering data and act on it. A tenant budget is enforced against measured spend, and when it is approached the system degrades deliberately — event-driven evaluation falls back to scheduled, lower-value evaluations are deferred — rather than stopping without warning.

Degrading is a design position. An agent estate that goes silent at a budget ceiling has failed in the most dangerous available way, because the absence of findings reads exactly like the absence of problems.

Metering records are part of the audit trail, not a separate telemetry system. That matters for a reason people do not anticipate: when somebody asks whether an agent examined a particular object before a decision was made, the run record is the evidence, and it needs the same integrity guarantees as everything else.

Where you bring your own key, metering still runs. Cost attribution is calculated against your provider's pricing so the numbers stay meaningful even when the bill arrives from somewhere else entirely.

Findings carry their own cost, which is a small detail with an outsized effect on conversations. Knowing that a particular class of finding costs a few cents to produce and routinely saves a week of investigation ends the abstract argument about whether AI is worth having.

Retention on metering records follows the audit trail's retention rather than a shorter telemetry window, because the question they answer — was this object examined before that decision — gets asked years later, not days later.

How it meets your ERP

AI spend is an operating cost that belongs in your accounts, and the metering export exists so it can get there — per-period totals broken down by agent and by cost centre where your tenant maps agents to one.

Chargeback and showback are both supported by the same data. Some organisations allocate agent cost to the programmes that generated the events; most start by showing it and allocating nothing, which is the sensible order.

Manufacturing PLM does not post journal entries or create transactions in your ERP. It produces an attributed export; what your finance system does with it is a decision for the people who own that system.

Where the boundary is

Metering measures; it does not optimise. It will not silently switch models, truncate context or reduce scope to save money. Those changes alter what the agents find, and a system that quietly degraded quality to hit a number would be reporting a cost saving it did not honestly achieve.

It also does not price your contract. The figures are token counts and computed costs at the rates configured for your deployment; commercial terms live in your agreement, not in a dashboard.