The price of an AI agent
is not its token price

An artificial-intelligence rate card is not a cost model. It prices selected inputs to a service. An agent may also call tools, search the web, retain context, retry, route work to another model, enter a hosted execution session and hand an exception to a person. The invoice can count every token correctly while leaving the buyer unable to say what one acceptable result cost.

Current supplier pages make the problem visible. OpenAI lists model charges across input, output and cached input and, for supported models, cache writes, with separate meters for tools, hosted execution and storage. Anthropic separates model input and output, prompt-cache writes and reads, batch processing, some server-side tools and managed-agent runtime. Google’s Gemini API distinguishes input, output including thinking tokens, context caching and storage, processing tiers, grounding and other tool use, with the exact meter varying by model and service tier. Salesforce now presents several Agentforce buying models: consumption-based Flex Credits and Conversations, as well as per-user licences, add-ons and editions; its worked examples explicitly exclude Data 360 credits and other consumption services. These are valid commercial choices, but they are not the same denominator. ^{1 2 3 4}

The management response is not to invent a universal conversion rate. It is to define the business task, set an acceptance threshold, count the entire attempt chain and compare cost per accepted outcome. That shifts the discussion from a vendor’s cheapest visible unit to the organisation’s own operating result.

The rate card stops before the work is finished

A token—a small unit of text or data processed by a model—is a useful engineering measure. It can reveal whether a prompt is bloated, whether caching is working and whether an architecture is pushing excessive context through an expensive model. It is a weak procurement outcome because it says nothing by itself about whether the task was completed, whether the result met the required standard or whether someone had to repair it.

Even apparently similar token rates may describe different operating conditions. Supplier documentation separates service tiers, context lengths, batch modes, cache operations, tools, search, storage, sessions, credits and entitlements in different ways. A low input rate can coexist with expensive output, repeated attempts or additional services. A bundled front end can include entitlements while still exposing consumption elsewhere. None of this shows that one supplier is intrinsically cheaper. It shows why a line-item comparison can be precise and still be decision-poor.

The FinOps Foundation distinguishes resource-efficiency unit metrics, including cost per token, from business unit metrics such as cost per transaction, cost to serve and cost per case resolved. Its current guidance says generative-AI unit economics often begins with token cost and expands towards outcome-oriented measures such as cost per assist, agent action or case deflected. ⁵ The useful buyer question is therefore not whether tokens matter. It is where they sit in the chain between technical use and an accepted business result.

Separate the capability signal from the management signal

Agent architecture can change what the system is able to attempt. Procurement needs a separate view of what those choices do to the operating cost and the result.

On a narrow screen, each signal is shown as a separate card.

The capability signal belongs to architecture and testing. The management signal belongs to procurement, finance, service ownership and governance. Confusing them produces a familiar error: treating a cheaper component as proof of a cheaper operating system.

Define acceptance before comparing price

The denominator must be agreed before the numerator is measured. For a contract-review agent, an accepted task might mean that every required clause is identified, the citations point to the correct text, prohibited disclosures are absent, the result arrives within the service window and the audit trail is complete. A plausible summary is not the same thing.

Risk changes the threshold. The voluntary NIST Artificial Intelligence Risk Management Framework 1.0 asks organisations to examine potential costs, including non-monetary costs, arising from AI errors or system functionality; define, assess and document human oversight; and demonstrate performance or assurance criteria in conditions similar to deployment. ⁶ It does not prescribe a procurement formula, accounting treatment or universal acceptance threshold. It supports a more important discipline: quality, risk and oversight are part of the outcome definition, not an afterthought applied to the cheapest run.

Different tasks can legitimately have different thresholds. Drafting an internal first pass may tolerate correction. Releasing a payment, advising a customer or changing a production system may require stronger evidence, human authority or a safe refusal. Comparability comes from holding the task and acceptance gate constant, not from pretending every use case has the same risk.

Count the entire attempt chain

The minimum useful equation is:

Cost per accepted task = (model use + tools and data + orchestration and hosting + retries and failed attempts + human review and exception handling + consistently allocated run and control costs) / accepted tasks

The terms should be defined consistently across offers. Implementation, support and governance may be fixed or shared rather than incurred on every task, but excluding them from one option while allocating them to another creates a false comparison. Exit and migration are better shown as explicit scenarios than hidden inside an arbitrary per-task number.

• Model activity: input, cached input, cache creation or writes, reasoning and output across every model used.
• Supporting services: retrieval, web search, connectors, tool calls, code or container sessions, storage and external data charges.
• Attempt effects: routing, validation, safety checks, retries, time-outs, abandoned runs and duplicate work.
• People effects: review time, rework, escalation, exception handling, supervision and the work needed to maintain controls.
• Commercial effects: seats, credits, minimum commitments, unused entitlement, rate tiers and any meter that does not roll over.
• Lifecycle effects: implementation, monitoring, support, change testing, portability, data export and termination work.

This is not an argument for making every calculation maximally complex. It is an argument for including the variables capable of changing the decision. A low-risk, high-volume workflow may justify a narrow marginal-cost view. A high-risk process with expensive exceptions may require a fuller cost-to-serve and risk view.

Run the Outcome-Normalised Agent Cost Test

Run the test on matched task sets and documented configurations. Capture usage at the point of work, reconcile it with billing data and time human work rather than guessing it. Report cost per accepted task alongside acceptance rate, reviewer time and exception cost. Add a sensitivity range for volume, context length, task mix and price changes.

On a narrow screen, each test field is shown as a separate card.

Have procurement name the commercial meters and commitments, engineering or the product owner map the technical events, finance agree the allocation rules, the service owner define acceptance and the operational reviewer time the human work. Do not compare a constrained pilot from one supplier with a production-like configuration from another.

Reconcile task identifiers, telemetry and invoices. Record refused, timed-out, abandoned and retried work rather than counting completed runs only. Report four measures together: cost per accepted task, acceptance rate, reviewer minutes and exception cost. Add a sensitivity range for volume, context length, task mix and price change. A single average is inadequate where a small number of difficult cases drives most of the cost.

Do not select an AI agent on token price until each offer has been converted into cost per accepted task, with exceptions and human work visible.

When the cheaper model becomes the dearer outcome

A simple hypothetical shows the ranking problem. Offer A has the lower model rate but creates more retries and more reviewer work. Offer B has the higher model rate but passes the agreed acceptance gate more often and sends fewer cases to an expensive exception process. Offer A wins a token comparison. Offer B may win on accepted-task cost.

That example is a possibility, not a finding that higher-priced models are generally cheaper. Only a representative pilot on the buyer’s workload can establish which pattern applies, and the observed economics should be treated as evidence for the tested configuration rather than a permanent forecast.

Questions for the procurement meeting

• What exactly is the billable unit, and which necessary services sit outside it?
• Which configuration choices change input, output, cache, tool, search, storage or session charges?
• What happens to cost when a task retries, routes to a stronger model, times out or fails?
• Which human reviews and exceptions are required to meet our acceptance threshold, and who pays for them?
• Can supplier usage records be reconciled to our task identifiers and finance data?
• What commitments, expiring credits, included entitlements or rate changes alter the realised unit cost?
• What must be exported or rebuilt if the model, platform or supplier changes?
• Which performance or savings claims have been reproduced on a representative set of our tasks?

The last question is the evidence boundary. Supplier price pages are first-party evidence of the list meters and packaging displayed on the recheck date. They are commercially interested, subject to change and may not reflect negotiated, regional or contract-specific terms. They do not prove workload savings, acceptance rates or bundle value. Those claims remain hypotheses until they survive matched testing using the organisation’s own standards.

What would change the judgement?

This framework should become simpler where evidence permits. If a stable workflow shows that token use reliably predicts accepted outcomes, tools and human exceptions are negligible, and contract exposure is immaterial, cost per token may be an adequate operational proxy. If invoice, task and review data show that the outcome-normalised ranking is stable across volume and configuration changes, the buyer can reduce the frequency of deeper tests.

The contrary evidence would also matter. A controlled, independently reproducible comparison that measures the full workflow may show that a higher advertised rate consistently produces lower accepted-task cost. Or it may show that model choice barely matters because integration and human review dominate it. The point is not to prefer expensive intelligence. It is to buy the least costly dependable outcome, with the denominator visible.

The rate card tells you what the supplier counts. The operating test tells you what the organisation receives.

Evidence note

Pricing and packaging were rechecked against the suppliers’ live official pages on 30 October 2026. Because those pages contain model-specific meters, service-tier differences, lifecycle changes and dated promotions, this article deliberately omits volatile list-price figures. Before live procurement, capture the applicable rate card and terms on the decision date and reconcile them with the configured architecture and contract.

Supplier pages can establish published meters and packaging on the recheck date; they cannot establish comparative workload performance, savings or realised buyer economics. The FinOps Foundation and NIST sources support broader unit-economics, risk and evaluation disciplines. The cost-per-accepted-task equation and buyer test are editorial synthesis.