Back to Blog
AI FinOps2026-09-16

FOCUS 1.5 Will Add AI Token Columns. Here Is What They Need to Get Right

FOCUS is the FinOps Foundation's open specification for billing data: a common set of columns so that a cost and usage export from one cloud looks like the export from another, and so tooling can be built once. Version 1.4 was ratified in June 2026 and added invoice reconciliation, billing period finality and commitment detail. It contains no AI-specific columns. That changes with 1.5, scheduled for December 2026, which is scoped to add cost visibility for AI models and tokens, a price sheet dataset, and cost attribution to people and agents.

The timing matters. The contribution window is open now, through the autumn, and the shape of those columns will decide whether AI spend can be reported in a FinOps tool the same way cloud spend is, or whether every vendor keeps its own token accounting and finance keeps reconciling by hand. In August the Linux Foundation also launched the Tokenomics Foundation to work alongside the FinOps Foundation on exactly this problem, with Finout, Vantage, Revenium, Pay-i, Cast AI, DoiT and about two dozen others as founding members.

We run a gateway that meters token usage across 16 providers in production, and we have spent a fair amount of the last year discovering the ways providers disagree with each other. This post is our input to the open call: the semantics that a token cost specification has to handle, laid out for finance teams and for whoever is drafting the columns.

A token is not one column

The early framing of the AI work was "model identity plus input and output tokens". That is where every provider started, and it is no longer enough to reconcile a bill.

A single request to a current frontier model can carry all of the following, each priced differently:

  • Prompt tokens: the input the model read.
  • Completion tokens: the output it wrote.
  • Cache read tokens: input served from a prompt cache, typically at a tenth of the input price.
  • Cache write tokens: input written into the cache, typically at a premium over the input price. On Anthropic, the premium depends on the cache lifetime you asked for, with five-minute and one-hour tiers priced differently.
  • Reasoning tokens: output the model generated while thinking and did not return, billed as output.
  • Modality tokens: audio and image input and output, priced separately from text.
  • Tool usage: web search calls and similar, billed per call rather than per token.

A specification with a single TokenQuantity column, or even an input and output pair, cannot price any of this correctly. At minimum the token type has to be a first-class dimension, with a controlled vocabulary broad enough to cover the list above and extensible for the next one.

The trap: providers do not agree on what "input" means

This is the part that has cost us the most engineering time, and it is the part a specification most needs to nail down, because the same word means different things on different invoices.

ProviderHow cached input is reportedWhat "input tokens" contains
AnthropicSeparate cache read and cache creation countsExclusive. Input, cache read and cache write are three non-overlapping buckets that add up to the total prompt.
OpenAIA cached tokens sub-countInclusive. Cached tokens are a subset of prompt tokens; the cached portion must be subtracted before pricing the rest.
Google GeminiA cached content token countInclusive, as OpenAI.
DeepSeekA cache hit and cache miss pairThe pair sums to the prompt count; neither is the "input" figure on its own.

Get the semantics wrong on Anthropic and you under-count input by the cached amount. Get them wrong on OpenAI and you charge the cached tokens twice, once at the input rate and once at the cache rate. The dashboards look healthy either way. The error surfaces weeks later, when someone compares the tool's number to the invoice and the two do not match.

For FOCUS this means the AI columns cannot simply carry provider-reported counts through unchanged. Either the specification defines a normalised semantics (we would argue for exclusive, non-overlapping buckets, which is what pricing actually operates on) and requires data generators to transform into it, or it carries the raw counts plus a column stating the provider's convention. The first is cleaner. The second is more honest about where the data came from. Either is better than silence, which is what a bare token count would be.

Three sources of truth, and none of them is final

Cloud billing has one source of truth: the bill. AI usage has three, and they disagree.

  1. The usage block in each response. Returned in-band, immediately, per request. This is the only source that can be attributed to a feature or customer, because it is the only one that arrives while the request context still exists. It is also occasionally absent (some streaming modes, some error paths) and occasionally wrong (a provider ships a model whose usage reporting lags the model itself).
  2. The provider's usage or cost API. Aggregated, delayed by hours to days, sometimes by API key, rarely by anything finer. Good for reconciliation, useless for attribution.
  3. The invoice. Monthly, authoritative, and carrying no business dimensions at all.

A few gateways and aggregators, OpenRouter and Vercel's AI Gateway among them, return the cost of each request in the response, which collapses the first two sources into one. Most providers do not.

FOCUS 1.4 added billing period finality for cloud data: a marker that says whether a row is provisional or settled. AI data needs the same, and it needs to be able to say which of the three sources a row came from. A row derived from in-band usage priced against a public rate card is an estimate until the invoice confirms it. Finance knows how to handle estimates. What it cannot handle is estimates presented as actuals.

Model identity is not a string

The price sheet dataset is the second big addition in 1.5, and for AI it has a keying problem.

Providers ship dated model versions and undated aliases that resolve to them. A request to an alias is served by a version, priced as the version, and the version can change under the alias. The same model is offered by several providers at different prices. Aggregators serve one model from several endpoints, and the price follows the endpoint that served the request, not the organisation that created the model. Providers also apply different rates by service tier, region and, increasingly, by cache lifetime.

A price sheet keyed on model name alone will be wrong most of the time. It needs, at least: provider, the model as billed (the resolved version, not the alias), the serving endpoint where that differs, the token type, the effective date range, and the unit. That is the minimum for a row in an AI cost dataset to be re-priceable, which is what makes it auditable.

Attribution to people and agents

The third addition in 1.5 is the one finance teams have been asking for the longest: who or what consumed the tokens.

The provider cannot tell you. The invoice has no idea which feature, customer, team or agent made the call, because the provider was never told. Attribution has to be captured at request time by whatever sits in the request path, and it has to be complete: an allocation model where a third of requests carry no dimension is not a model, it is a residual.

Agents make this more pressing rather than less. An agent runs many model calls on behalf of a task, often across several models and providers, and the task is what the business cares about. The natural allocation key is the agent identity and the workflow that invoked it, with the person or team that owns the agent as the cost centre. The columns should allow for that shape: an agent as a first-class allocation dimension, distinct from the human user and distinct from the API key, so that "cost per agent run" is a query rather than a reconstruction.

What finance teams should ask for now

Whatever the final column names, these are the questions to put to any vendor claiming to report AI spend, and they are the same questions the specification should force an answer to.

  • Which token types do you capture separately? If cache reads, cache writes and reasoning tokens are folded into input and output, the numbers will not reconcile.
  • How do you handle each provider's cache semantics? If the answer does not distinguish Anthropic from OpenAI, the tool is wrong on one of them.
  • Where does each row come from, and is it final? In-band usage, a usage API, or the invoice, and whether the figure has been reconciled.
  • What is the price keyed on? Alias or resolved version, provider or serving endpoint, and whether the rate card is dated.
  • Is attribution complete? What percentage of spend lands in an unallocated bucket, and whether untagged requests can be refused at the gateway.
  • Can an agent be an allocation key? Or is everything attributed to the API key that happened to be used.

Where we stand

AI SpendOps handles the provider semantics above in production: the token types are captured as separate quantities, the inclusive and exclusive cache conventions are normalised per provider before pricing, aliases are resolved to billed versions, and attribution dimensions are captured at the gateway and can be made mandatory. We are publishing this as our contribution to the 1.5 process because the gap between "input and output tokens" and what a reconcilable AI cost row actually needs is one we have already had to close, and the specification should not have to rediscover it.

FOCUS 1.5 is due in December. The columns are being drafted now. If you run a FinOps practice and AI spend is on your books, this is the window to say what you need the data to look like.

Further Reading

Sources