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

Cost data can name the AI model and who built it.

Four recommended FOCUS-defined properties in SKU Price Details record the model behind a charge: the developer that created it, the model family, the model identifier as billed, and the version. Developer, family, and version read the same way whether the model is bought from its developer or served by a cloud provider; the model identifier is recorded as each provider bills it.

Why it matters. This is the piece that makes multi-provider AI spend comparable. Without it, an organization can total what it spent on models last quarter but cannot break that down by model without provider-specific parsing.

Cached tokens separate from uncached ones, and input from output, on the price itself.

Two recommended FOCUS-defined properties label token prices: how the tokens interacted with a prompt cache, and whether they went into the model or came out of it. They normalize cache and token meter names that differ from one provider to the next.

Why it matters. Cached input tokens often cost a fraction of uncached ones at the same provider; in the specification's worked example, a cache read costs a tenth of the input price. Without a common label, separating a fall in cache hit rate from a rise in traffic means matching each provider's meter names by hand, so one of the most actionable AI optimization levers is hard to track across providers.

Worked examples for mapping AI model billing into FOCUS.

Six worked scenarios, each with sample data, showing how token billing maps onto existing FOCUS columns, plus an AI Model Billing supported feature with example queries. No columns are added: FOCUS already has the columns to carry token consumption, and the gap these close is applying them the same way.

every single one has a different data formatA FinOps practitioner managing 20-plus AI providers

Why it matters. When FinOps Practitioners cannot tell how existing columns apply to AI billing, every provider gets normalized differently. Shared examples give data generators and practitioners one reference for the arrangements they meet most.

Cost rows can name the principal and the credential behind an AI charge.

Three new Cost and Usage columns. Principal ID identifies the user, service account, or other identity granted access. Credential ID identifies the credential presented on the request, such as an API key or a session. Requester Details carries the attributes a provider publishes for each, such as a display name, type, and email address.

Why it matters. As spend shifts from provisioned infrastructure to per-call model invocations, the question changes from which account owns an instance to which developer, team, or automated agent used the tokens. These columns answer it inside billing data rather than by joining to observability.

Provider-issued credits can be recorded as a consumption currency.

The currency rules now recognize a consumption currency: a provider-issued unit such as platform credits or normalized billing units. ISO 4217 currency codes are reserved for national currencies.

Why it matters. Much AI usage is priced in a provider's own credits or billing units. The price can now be recorded in that unit, alongside the billed cost in national currency. Prepaid spend in a national currency is a different case. The worked examples in final review show one such arrangement: a token prepayment recorded as a commitment and drawn down by usage.

Common unit names for multimodal and agentic usage.

The recommended unit names now include Character, Image, Job, Message, Page, and Session alongside Token and Request, each with a description.

Why it matters. Without common names, providers describe multimodal and agentic usage in their own strings, so unit costs cannot be compared without mapping each one by hand.

A SKU Price dataset publishes token rates before anyone spends.

A new dataset carrying a provider's prices on their own, separate from consumption: list and negotiated token prices, the dates each applies, quantity tiers, and the accounts eligible for a price. Each price connects to the cost rows billed at it through the SKU Price ID that Cost and Usage already carries.

Why it matters. This is where an organization reads a provider's published token rates, prices a planned workload against them, and tests what a negotiated rate is worth. For a model not yet used, the rate is found by the provider's SKU ID or description; the normalized model properties reach a catalog price only through usage already billed.

Service categories that no longer assume cloud, with bare metal apart from virtual machines.

Service Category descriptions are rewritten to apply to any technology provider, and a new Bare Metal subcategory separates physical servers from virtual machines.

Why it matters. AI spend often arrives from providers that are not clouds, and GPU capacity is often bought as bare metal. Service categories now describe those providers, and bare metal classifies apart from virtual machines.

Distinguishing globally served models from region-pinned ones.

A property for the region scope of a price: whether it applies to global serving or to a specific region. Postponed in September, with its name and its relationship to the SKU Price dataset still open.

Why it matters. Global and regional serving carry different rates and different data residency characteristics, so this is a finance question and a compliance question at once.

Two follow-ons to the requester columns.

Scoped detail configuration, letting a practitioner choose optional, higher-cardinality detail such as principal-level attribution for parts of a dataset, and a Consumer ID column.

Reasoning tokens, which are billed but never appear in the response.

Reasoning models charge for intermediate tokens the customer never sees, so output token counts in application logs do not match the invoice. Partly answered in 1.5: a separately metered reasoning token carries token direction "Output", so it is counted with output tokens. A dedicated treatment, including reasoning effort, remains open.

The standing charge for keeping a context cache.

Context caching can bill on two axes: the tokens processed, and the content held over time. The second behaves like a storage charge and accrues whether or not the cache is read. In 1.5 these charges carry neither token property; a dedicated treatment remains open.

Input modality: text, image, audio, and video.

Multimodal traffic is billed per token, per image, per second of audio, or per frame, depending on provider and input. 1.5 adds common unit names for several of these, but a modality classification and recommended meter values remain open.

Prices that change with context window size.

Several providers price the same model differently above a context length threshold. Without the distinction, a cost increase driven by longer prompts looks the same as one driven by more calls.

Priority, standard, and batch inference tiers.

Batch and off-peak processing is commonly discounted by about half against real-time inference. Making the tier visible would turn "move this workload to batch" into a measurable saving.

Provisioned throughput as a commitment.

Committed AI capacity is structurally similar to a reserved instance or savings plan. The open question is whether it maps onto the existing commitment discount model cleanly or needs its own treatment. It is where committed AI dollars sit and where utilization against them is measured.

Deeper AI service subcategories, including Agentic AI.

Layered subcategories would separate the infrastructure an AI workload runs on from the model serving it and the application consuming it. Today those layers can land in one subcategory, which is why "what did AI cost us" is hard to answer the same way across organizations.

Tool or harness identity, application session and event identifiers, and per-request token limits.

Set aside during the AI billing examples and model identity work. Per-request token limits are request configuration rather than billing data, and application session and event identifiers are observability join signals with no home in FOCUS; they are distinct from the authenticated session that Credential ID can carry. Tool or harness identity was left out of the first pass of examples.