Introduction
Every cost figure in AI Governance is derived, not measured. Nothing bills you and nothing reads your invoice — a number of tokens is observed, a rate is applied, and the result is attributed to an agent and a model. Each of those three steps can be imperfect, and knowing where explains every discrepancy you will encounter.
The derivation chain
An instrumented agent emits a trace — If nothing is sent, nothing exists. This is the first and largest source of missing cost.
Model calls within it become spans — One span per call, carrying which model was called.
Each span carries token counts — Input and output tokens (and cache reads and writes where reported), either reported by the provider or derived from the content.
A rate is applied — Tokens multiplied by a per-token price for that model.
The result is attributed twice — To the model that was called, and to the agent whose trace it was. The same money, indexed two ways.
Note: The chain runs one way, and every link is lossy in the same direction. Untraced work, unreported tokens and unknown models all cause spend to be under-counted, never over-counted. A cost figure in this product is a floor, not a ceiling.
Where token counts come from
There are two possible sources, and they are not equally reliable:
Source | Accuracy | Available when |
Reported by the provider in its response | Authoritative — it is what you will be billed on | The provider returns usage and the instrumentation captures it |
Derived from the content | Approximate — tokenisation differs by model family | Nothing was reported |
Reported counts are preferred wherever they exist, for the obvious reason: they are the same numbers the provider will invoice. Derived counts are a reasonable estimate and should be treated as one.
The practical consequence is that cost accuracy varies by integration, not by agent. Two agents doing identical work through different providers can carry differently trustworthy figures, and nothing on the screen distinguishes them. If precision matters for a particular workload, confirm with your account team whether that provider reports usage.
Where rates come from
A token count is not money until a rate is applied. Rates are per model, and differ between input and output tokens — output is typically the more expensive of the two, which is why a verbose agent costs more than a terse one at identical request volume.
Rates come from the model pricing catalogue, per 1M tokens — input, output, cache read and cache write, plus audio, image and per-minute rates where relevant — and are refreshed every 15 minutes. Cached tokens are priced separately (cache read / cache write) and are not billed as input, so caching is reflected for UnifyApps-traced calls. Eval cost comes from evaluation runs.
Two things follow that are worth designing around:
A model with no rate is costed at $0. Its usage is still observed, so it shows activity and no spend.
Catalogue rates are list prices. They do not know about your commercial agreement.
Why this differs from your provider bill
This is the most common question about cost in this product, and every cause is legitimate:
Cause | Direction |
Uninstrumented traffic | Cost Explorer reads low |
Negotiated or committed-use discounts | Cost Explorer reads high |
Batch pricing | Cost Explorer reads high |
Free tiers and credits | Cost Explorer reads high |
Models with no rate available | Cost Explorer reads low |
Billing month vs rolling window | Either |
Non-inference charges — storage, hosting, egress | Cost Explorer reads low |
"Cost Explorer is right about which agent spent the money. Your invoice is right about how much. Do not ask either one to be the other."
Contract pricing is not currently something this KB can tell you how to apply. If your negotiated rates differ materially from list and you need reporting to reflect them, raise it with your UnifyApps account team rather than adjusting figures by hand downstream.
Cost is not only inference
Running agents produces spend in more than one category, and treating all of it as model cost hides the parts you can most easily control. Governance and evaluation both cost money — an LLM-based check is a model call, and an AI judge is a model call per scored session.
Two consequences worth planning for:
Turning on evaluation increases spend. The product says so where you configure it: an AI judge "adds spend every session". Sampling is the control — see Evaluation Cost.
Turning on LLM-based controls increases spend. A custom check on every request is an extra model call on every request. Deterministic checks — regex, blocked tools — do not carry that cost, which is a reason to prefer them where they can express the rule.
Spend that belongs to nothing
Some observed spend cannot be attributed to a specific agent or outcome. It is real, it is counted, and it will not appear in any breakdown that requires an owner.
This is why a return-on-spend figure is only ever a statement about measured spend, and why the honest way to quote one is alongside how much spend was measured. See Reading the ROI View.
What actually moves the number
Shorten the context — Input tokens are usually the larger share, and the largest input is usually context nobody has audited. This is the highest-yield change in most agents.
Cut retries — A retry doubles the cost of a run and produces nothing. Retries show as an unusual trace shape.
Match the model to the task — Not every step needs the largest model. Model view shows where the expensive one is being used.
Sample evaluation rather than scoring everything — Coverage has diminishing returns; cost does not.
Prefer deterministic checks where they express the rule — A regex costs nothing per request. An LLM check does.