AI agent cost tracking: measure cost per outcome, not per token

The model got cheaper. The case got more expensive.

A retailer runs an AI application that handles delayed-refund disputes. It pulls the order, payment, shipment and customer history, calculates whether a refund applies, asks a model to classify the dispute, checks policy, escalates some cases to an analyst, and issues the refund when it's authorized.

Finance watches the model invoice closely. The model costs $0.11 per case. Seven percent of cases go to a person. Counting data access, compute, inference, review, retries and platform share, the whole route costs $1.72 per resolved case.

Then someone swaps in a cheaper model at $0.06 per call. The model dashboard shows a 45% saving.

The cheaper model leaves more classifications incomplete. The route retrieves again, falls back to a stronger model more often, and now sends 19% of cases to review. Some cases sit in the queue long enough that their data must be refreshed and policy rechecked. The full route now costs $4.38 per resolved case.

The retrieval service, review queue, runtime and policy service each reported their own numbers correctly. Nothing connected them to the same case and the same result. The team optimized the most visible line item instead of the unit that mattered.

Why isn't token cost the real cost of an AI agent?

Because tokens price one input, not the result. A single agent case also consumes data access, compute, policy checks, durable state, human review, retries, recovery and shared platform capacity, and those often outweigh the model call.

Model providers meter usage precisely, which is why their invoices dominate cost conversations. But one run of an AI application touches many cost surfaces:

You don't need to allocate every microsecond. You do need a declared boundary and an explicit unit, instead of treating the easiest invoice to read as the economics of the whole system.

Choose the unit before you measure

Cost can be reported at several levels, and each answers a different question:

The outcome unit should be stable enough to compare routes over time and meaningful enough to reflect what the application exists to do. Pick it before you start optimizing tokens.

What does an AI agent actually cost per case?

The sum of every cost event tagged to that case: direct charges like model calls and queries, a declared share of platform costs, human minutes, and the cost of retries and recovery, divided across outcomes by class.

To get there, every cost needs application identity. Billing exports and infrastructure telemetry identify an account, service, model, region and period. They don't know which case, step or approval consumed the money. A cost record that can be attributed carries:

• quantity, unit, currency, time and measurement source;
• cost category, and whether the amount is direct, allocated or estimated;
• provider, service, model, region or human work type;
• the workflow version, run, step and attempt;
• tenant, application and tool;
• the business action, its approval and the confirmation from the system of record;
• the allocation method and price basis used.

This doesn't replace invoices, payroll or finance systems. It links their authoritative numbers to the same case and outcome. Open billing specifications such as FOCUS normalize cost and usage data across providers, and OpenTelemetry's generative AI conventions standardize token and tool usage signals. Neither knows which approval, retry or business effect consumed the cost. Your application has to supply that join.

How do you allocate shared AI platform costs?

Choose an explicit driver for each shared cost, version that method, and label allocated amounts as allocated, so nobody mistakes an accounting choice for a measured fact.

Some costs attach cleanly to one run: a model request, a query, an API charge, an analyst's review. Others are shared:

• private inference capacity reserved for several applications;
• building and refreshing vector indexes;
• feature computation used by many workflows;
• runtime, event and evidence infrastructure;
• identity, policy and platform operations;
• idle capacity kept for failover or residency.

Reasonable drivers include tokens, GPU- or CPU-seconds, rows scanned, storage byte-days, run count or duration, human minutes, or a share of reserved capacity. The choice is a management decision, and different drivers can change a workflow's unit economics materially. So keep the method versioned and visible, and don't manufacture precision. An estimated or imperfectly allocated amount should say so.

When is an AI cost number final?

Often weeks after the case closes. Provider billing, commitment discounts, human time entries and period-end allocations arrive late, so every cost needs a status: estimated, provisional, final or corrected.

Keep both what was known at decision time and what became known later. Otherwise you can't tell bad routing from normal billing finalization.

The same split applies to routing. A route decision needs a forecast: expected cost, latency and review rate for each allowed option. Accountability needs the realized number: what the route actually cost once retries, waits, escalations and corrections are in. The variance between the two is evidence for the next routing and budget decision, not noise to hide across five dashboards.

A budget check should never optimize cost on its own. A cheaper route that can't meet the required quality, authority, privacy, residency or evidence conditions isn't a cheaper option. It's not an option. (See model routing across cost, latency, quality and policy.)

Keep outcome classes separate

The same route produces outcomes with very different economics:

A route with a low average inference cost can still be the expensive choice if it produces high rates of escalation, repeated model calls, uncertain writes, manual reconciliation or reversals. Report cost per automated resolution, per human-resolved case, per declined case and per corrected outcome separately before blending them into one portfolio average. (Uncertain writes have their own cost trap; see retries and idempotency.)

Human time and waiting time need their own views

On hard cases, human review often dwarfs the model call. Capture the work type and duration without reducing people to a compute meter: active review versus queue time, approval versus adjudication, specialist versus generalist, and productive decisions versus rework caused by poor evidence or bad routing.

Waiting has a cost too, even when no meter runs. A delayed refund or onboarding can breach a service level or lose a customer. Don't silently convert that into currency without a documented method. Keep three views that aren't interchangeable:

• Attributed cost: measured and allocated money.
• Operational burden: human minutes, queue time, retries, unresolved work.
• Business impact: the value of delay, error, risk or success under a declared model.

Keeping them apart prevents double counting and lets finance, operations and business owners each apply the method that fits their decision.

A stitched stack reports every cost and hides the economics

An AI gateway reports tokens. A search service reports queries. A workflow engine reports executions. A policy service reports decisions. A review tool reports queue time. The cloud bill reports resources. All accurate, and still nobody can answer: which route produced this outcome, which costs came from retries, which model saving caused more review, which workflow version used the shared capacity, and which result needed a later reversal?

The missing piece isn't another dashboard. It's a shared identity that ties cost, execution, decision and effect together, recorded as the work runs. Bolting it on after deployment rarely works, because the identities you need for historical attribution were never captured.

Keep carbon beside cost, not inside it

Money and resource intensity are related but not the same. A route can be cheap under a discounted contract while burning a lot of compute; another can cost more yet run on low-carbon infrastructure or avoid repeated inference. The Software Carbon Intensity specification measures carbon as a rate per declared functional unit, which maps neatly onto your outcome unit: energy or carbon per resolved case. Track it as its own measure. (See token efficiency and green AI.)

Common anti-patterns

Ten rules for AI cost attribution

1. Define the outcome unit before optimizing tokens or model price.
2. Treat model usage as one cost among many in the run.
3. Tag every cost with workflow version, run, step, attempt and business action.
4. Separate direct, allocated, human and recovery cost.
5. Version the attribution boundary and every allocation method.
6. Keep estimated, provisional, final and corrected values; never overwrite.
7. Compare forecast route cost with realized route cost, and record why they differ.
8. Judge cost alongside quality, policy, authority, residency, evidence and latency.
9. Report automated, human-resolved, declined, uncertain and corrected outcomes separately.
10. Keep the link from spending to outcome, so you can explain what the money produced.

The result: a unit you can actually govern

Provider invoices and token counters are necessary. They can't tell you whether an AI application is getting more economical. Its cost lives across the whole route: context, compute, inference, policy, state, human judgment, retries, evidence and external effects.

Once those costs join to the same run and outcome, you can ask a better question than "which model is cheapest?": which allowed route produces a valid, authorized, evidence-complete result for the least total resource and operating burden? A model call is a line item. A governed outcome is the unit of economics.