What 1.5 does for AI cost, and what it does not

What it adds

Four FOCUS-defined properties on SkuPriceDetails: ModelDeveloper, ModelFamily, ModelId, and ModelVersion. No new columns, and no change to the existing SkuPriceDetails requirements, so this is additive for every data generator.

It also lands a worked appendix example with two scenarios and backing CSV data: a model purchased directly from its developer, and the same model resold by a cloud provider as a first-party service. The second scenario is the one practitioners get wrong today, because the service provider and the model developer are different companies.

A deliberate omission

The input versus output token split is carried structurally, as separate SKUs distinguished by SkuMeter, rather than through a dedicated token-type property. That decision is revisitable and is tracked in bucket 4.

Why it matters

This is the piece that makes multi-vendor AI spend comparable. Without it, an organization can say it spent a given amount on models last quarter but cannot break that down by model without vendor-specific parsing.

What it changes

Rewrites the ServiceCategory descriptions that referred to "cloud" so they apply equally to hybrid, SaaS, and on-premises environments, and moves Multicloud into alphabetical position. Strictly backward compatible: no allowed values added, removed, or renamed.

Context for AI

An "AI and Machine Learning" service category already exists, with subcategories for AI Platforms, Bots, Generative AI, Machine Learning, Natural Language Processing, and Other. This work removes the cloud-only framing around it, which mattered because a large share of AI spend now arrives from vendors that are not cloud providers.

The problem it answers

The gap is not the schema. FOCUS already has the columns needed to carry token consumption. The gap is that practitioners cannot tell how those columns apply to AI billing, so every vendor gets normalized differently.

every single one has a different data formatBecky Canterbury, Shutterstock, on working with 20-plus AI vendors

Requested by NatWest, SLB, UK Government Digital Service, Shutterstock, Syngenta, Anglepoint, AWS, and the FinOps Foundation.

What it delivers

Non-normative worked examples with backing datasets, scoped deliberately to already-defined FOCUS columns and properties. A scenario needing an undefined concept becomes a separate proposal rather than inventing something inside an example. Five scenarios carry through, with deliberate variety in SkuMeter so the set does not read as prescriptive.

Open work

• Draft the example set. Due 5 Aug, and the item everything else here waits on.
• Add a prepayment drawdown example. Due 13 Aug. The Task Force found the current set misses the most common real pattern: capacity bought up front, drawn down by usage, so billed cost is zero on usage rows and effective cost reflects amortized consumption.
• Add Kimi on Fireworks AI and further vendor examples. Due 29 Jul.

What it adds

A PrincipalId column on the Cost and Usage dataset, identifying the actor behind a charge.

Why it belongs in the AI story

This is the attribution primitive behind per-user and per-agent cost. As spend shifts from provisioned infrastructure to per-call model invocations, the question changes from "which account owns this instance" to "which developer, team, or autonomous agent burned these tokens." PrincipalId is what makes that answerable inside billing data rather than by joining to observability.

Live decision

A companion IdentityDetails column, carrying attributes such as name and email, is a separate open question for 1.5. It appears in bucket 3.

What it adds

A new SKU Price dataset, carrying prices independently of consumption. Column naming is being settled in parallel, replacing ContractCommitmentDurationType and ContractCommitmentPaymentModel with PurchaseDurationType and PurchasePaymentModel.

The connection to AI

The model-identity properties delivered in bucket 1 describe a SKU price, not a usage row. The SKU Price dataset is what lets an organization compare model rates across vendors before committing spend, rather than discovering the comparison after the invoice arrives. It is the difference between reporting on AI cost and negotiating it.

What it covers

A review of how tokens, credits, and crypto are handled as virtual currency in the CurrencyFormat attribute.

Why it matters for AI

A large share of AI spend is transacted in something other than a national currency. Buyers purchase token bundles or platform credits up front and draw them down. If FOCUS treats those units inconsistently, prepaid AI spend either disappears from cost reporting or double counts against the cash that bought it. This work and the prepayment drawdown example in FR 1941 address two halves of the same problem.

What it is

Supporting content rather than a specification change. It is the narrative piece that explains the position to an audience that will not read column definitions.

Worth flagging separately because it is the only item on this page a board audience would read end to end, and it is due before the August 13 gate.

Cached and uncached tokens can differ in price by an order of magnitude at the same vendor. Without the distinction, a rise in token cost cannot be separated from a fall in cache hit rate, so the single most actionable AI optimization lever is invisible in cost data.

Reasoning models charge for intermediate tokens the customer never sees. Finance teams reconciling an invoice against application logs find output token counts that do not match the bill, with no standard field explaining the gap.

Context caching bills on two axes: the tokens processed, and the storage held over time. The second behaves like a storage charge rather than a usage charge, and it accrues whether or not the cache is read.

Adds input modality classification along with recommended SkuMeter values. Multimodal traffic is billed per token, per image, per second of audio, and per frame, depending on vendor and input type. Without a modality dimension, those units collapse into an aggregate that cannot be compared or forecast.

This is a larger piece of work than the other price-detail items in this bucket. The modality classification and the recommended meter values are two jobs rather than one, which puts it outside the set that could realistically be picked up before 13 August.

Several vendors price the same model differently above a context length threshold. The rate change is invisible in cost data today, so a cost increase driven by longer prompts is indistinguishable from one driven by more calls.

The only item in this bucket with neither an owner nor a task force assigned.

Batch and off-peak processing tiers are commonly discounted by half or more against real-time inference. Making the tier visible turns "move this workload to batch" from an intuition into a measurable saving, and lets an organization verify it actually happened.

Global and regional serving carry different rates and different data residency characteristics. This is one of the few AI cost dimensions that is simultaneously a finance question and a compliance question, which makes it awkward to leave undeclared in billing data.

Provisioned throughput is a commitment purchase, structurally similar to a reserved instance or savings plan. FOCUS already has a mature commitment discount model. The question is whether provisioned AI capacity maps onto it cleanly or needs its own treatment.

Of everything in this bucket, this is the one most likely to matter at the level of a board conversation, because it is where committed AI dollars sit and where utilization against those commitments gets measured.

Extends the existing AI and Machine Learning subcategories to support layered analysis, separating the infrastructure an AI workload runs on from the model serving it from the application consuming it. Today those three layers can all land in one bucket, which is the reason "what did AI cost us" is hard to answer consistently across organizations.

The decision

Does an IdentityDetails column draft against the August 13 gate in 1.5, or does 1.5 ship PrincipalId alone with identity attributes carried into 1.6 as a straw man?

The case for waiting

PrincipalId alone is enough to join identity attributes in from elsewhere. Shipping it first lets community feedback tell us whether name and email are actually wanted in cost and usage data before personally identifiable fields are published into it. A privacy review on the question is outstanding.

Request-level configuration sits closer to observability than to billing, consistent with the feature request's own exclusion of telemetry. It was not routed to any of the parallel AI feature requests, so it is a deliberate stop rather than a deferral.

Ruled out of the first example pass. This is the one most likely to come back, because agentic tooling is exactly where attribution questions are heading. It is a sequencing call, not a rejection of the concept.

These are observability-side join signals with no FOCUS-defined home. Billing data does not carry them, and inventing a place for them inside FOCUS would put the specification in the business of describing application telemetry.

Open rather than closed. Today the split is carried structurally, through separate SKUs distinguished by SkuMeter, which is what shipped in bucket 1. Whether it should instead become a first-class column or defined property is explicitly deferred, not settled. Worth knowing if anyone asks why token type is not a column.

The gate is mechanical, and it is what keeps a release predictable. Ten items sit in bucket 3 today. How many move here is known in 16 days, and the 1.6 scoping window opens 29 October.