Do not commit to tokens before you can price a successful task

A precise rate card can sit on top of an unstable demand model

The hard part of an AI consumption contract is not multiplying tokens by a published price. It is knowing what creates the tokens, what else is billed, how often a task retries, whether the output succeeds, and which contractual protections survive a model, rate, or product change.

FinOps Foundation guidance describes several ways organizations acquire AI: direct provider APIs, cloud marketplaces, self-hosted models, AI embedded in software, and developer tools. Those routes produce different bills and different control points. A direct API may expose model and token classes. An embedded assistant may mix seats, credits, platform actions, and limits. A marketplace may add another agreement and invoice path. A self-hosted model shifts cost toward infrastructure, operations, and capacity.

The commercial problem is therefore architectural. Before evaluating a discount, the buyer must map the full chain from a business event to an AI request, model route, prompt and context, cached content, output, tool execution, retry, human review, invoice line, allocation owner, and successful outcome. A missing link makes the forecast less auditable and the commitment more speculative.

Practitioner discussion in Procurement and FinOps communities reflects that uncertainty. Recent buyers described volatile usage and a need to learn before committing. Those posts are directional experience, not market statistics or contract authority. They support a sensible operating principle already implied by formal FinOps practice: observe the workload, assign ownership, and make commitment decisions from evidence rather than enthusiasm.

Forecast business demand, not an abstract pool of tokens

A useful forecast begins with a workload register. “Customer support assistant” is too broad. Split it into tasks such as classify an inbound case, retrieve an approved answer, draft a response, summarize a call, and escalate a policy exception. Each task has a volume driver, allowed models, context source, success definition, failure mode, and review requirement.

Monthly workload cost =
successful tasks
× attempts per successful task
× (input + cache write + cache read + output + tool + runtime cost per attempt)
+ fixed seats or platform charges
+ human review and operating cost
- applicable credits

Cost per successful outcome = total workload cost / accepted outcomes

This formula deliberately keeps attempts and success visible. Research published in 2026 argues that token reduction alone can be weakly related to total cost when providers price token classes and models differently, and proposes success-adjusted billed cost as a more useful efficiency measure. Another recent paper highlights the audit difficulty of per-token billing when tokenizer, model choice, or execution details are hidden. These papers should inform controls, not be treated as universally proven savings ratios.

Run a bounded 30-to-60-day observation window when practical. Capture normal days, peak days, a period-end or campaign spike if relevant, and known failure cases. Remove training tests and accidental loops from the expected baseline, but retain them in a stress scenario. A contract that models only clean production requests ignores one of the most expensive properties of automation: it can repeat quickly.

A transparent scenario example

Assume, purely for illustration, that a team expects 20,000 eligible tasks a month. It models 50% adoption, 1.25 attempts per accepted task, and an average AI charge of $0.07 per attempt across tokens and tools. The modeled AI charge is 20,000 × 50% × 1.25 × $0.07 = $875 per month before fixed fees, human review, credits, tax, or currency effects. If adoption reaches 80%, attempts rise to 1.6, and the routed model mix raises charge per attempt to $0.11, the same calculation becomes $2,816.

The example is not a benchmark or vendor quote. Its purpose is to expose sensitivities. A buyer who commits from the first number without protecting against the second has not modeled the workload. A buyer who commits from the second without validating adoption may prepay unused capacity. Compare a small commitment, the proposed commitment, and pay-as-you-go under all three scenarios. Show both unused commitment and overage, not only the discount.

Turn commercial uncertainty into a clause matrix

The review team should not ask an AI system to generate final legal language. It should create a controlled matrix that identifies the current term, risk, negotiation objective, qualified owner, and disposition. Counsel and Procurement can then work from a complete commercial model rather than discovering technical meters after signature.

A reopener is not a vague promise to “discuss in good faith.” Define an observable event, measurement period, evidence, notice, remedies, and decision owner. Candidate triggers might include a material rate increase, a required model retirement, a new meter, repeated reconciliation failure, a specified usage variance, a regulatory restriction, or an agreed service degradation. Thresholds and legal effect must be negotiated for the actual deal.

Commitment flexibility can be more valuable than a larger headline discount. Test whether value can move across models, products, accounts, regions, and affiliates; whether credits expire; whether usage draws down oldest value first; and whether the buyer can see the balance. Confirm whether marketplace commitments, enterprise cloud discounts, and the AI provider commitment interact or remain separate.

Common failure modes and controls

Do not reward a team only for consuming the commitment. That converts prepayment into a target and can encourage low-value use. Measure accepted outcomes, avoided work where valid, service quality, risk, and cost together. Unused value is a planning signal, not a reason to manufacture demand.

Frequently asked questions

How long should an AI pricing pilot run?

Long enough to capture normal work, known peaks, adoption behavior, retries, and at least one complete reporting and invoice cycle where practical. Thirty to sixty days is a useful planning window, not a universal rule. Seasonal or period-end workloads may need a longer observation or explicit stress case.

Is a token commitment the same as reserved capacity?

Not necessarily. A monetary or usage commitment may buy discounted consumption without guaranteeing throughput. Provisioned capacity may reserve throughput with different utilization and overage economics. Read the applicable service and pricing schedules and model each arrangement separately.

Should Procurement compare providers by price per million tokens?

Only as one input. Tokenizers, model capabilities, token classes, cache rules, tools, runtime, reliability, and task success differ. Compare total billed and operating cost for the same accepted workload, with security and service requirements held constant.

What if the vendor cannot export detailed usage?

Treat that as a control gap. Reduce the scope or commitment, require an alternative report or API, improve buyer-side metering, define a reconciliation and dispute process, or keep the status at pilot only. Do not claim auditable allocation when the evidence is absent.

Can an AI tool review the contract itself?

It can extract terms, compare them with a buyer-approved checklist, model supplied data, and prepare questions if the tool is authorized for the material. It cannot provide the final legal, financial, accounting, security, or business approval. Qualified humans must inspect the original documents and calculations.

What is the most important renewal metric?

No single metric is sufficient. Start with cost per accepted business outcome and pair it with volume, quality, latency, risk, human review, allocation, forecast accuracy, and remaining commitment. A declining token count is not proof that the contract produces more value.