azCloudOps

A token bill tells you what was consumed. It rarely tells you who consumed it. FOCUS 1.5, targeted for ratification on December 3, 2026, is the first version of the FinOps billing standard that puts both answers in the same record: the model and token type on the price, and the calling identity on the row. This piece explains what token-level cost allocation is, what 1.5 changes, and what you can build on Azure, AWS and Google Cloud before your providers ship it.

In this article

• What is token-level cost allocation?
• What changed: the two keys in FOCUS 1.5
• What you can build today on each cloud
• Where it is heading (analysis)
• What to do next, by role

Who should read this

FinOps practitioners who own showback or chargeback for AI, platform teams that run a shared model gateway, and security teams that issue API keys and service identities to applications and agents.

What is token-level cost allocation?

Token-level cost allocation means splitting AI spend by the units the model actually bills, and assigning each slice to the team, product or agent that caused it. A token is the unit most language models charge for. Input tokens, output tokens and cached tokens are usually priced differently, so a single “AI services” line on a bill hides most of what matters.

An everyday comparison: a shared office phone bill. Knowing the total is useless for chargeback. You need two things on every call: what kind of call it was (local, long distance, international) and which extension made it. Token allocation needs the same two keys: what kind of token was consumed, and which caller consumed it.

What changed: the two keys in FOCUS 1.5

FOCUS, the FinOps Open Cost and Usage Specification, is the vendor-neutral schema for billing data. The current published version is 1.4. The working group’s FOCUS 1.5 release scope page, updated in October 2026, sets approval and ratification for December 3, 2026, after an IP rights review running from November 2 to December 1. The page states that nothing on it is a commitment until the Steering Committee ratifies the release.

For allocation, the 1.5 working draft adds two groups of fields. Together they are the two keys.

Key 1: what was consumed

These are recommended FOCUS-defined properties in SKU Price Details, not new columns. They are recommended, not required, so a provider can be conformant without them.

Property	What it holds
ModelDeveloper, ModelFamily, ModelVersion	Who built the model, its family and its version
ModelId	The model identifier as billed, which can differ by provider
TokenDirection	Input or Output
TokenCacheAction	Uncached, Read, Write or Other

The scope page describes the two token properties as the first SKU Price Details properties with a fixed set of allowed values. That matters for allocation: a fixed list can be grouped and compared across providers without a mapping table.

Key 2: who called it

These are new columns in the Cost and Usage dataset. All three requester columns are conditional, governed by a new requester attribution operating model condition.

Column	What it holds
PrincipalId	The user, service account or identity granted access. Stable across credential rotation.
CredentialId	The credential presented, such as an API key or session
RequesterDetails	A JSON array of requester attributes, validated by a JSON schema
AllocatedServiceName	The service a split charge is allocated to, on split-allocated rows

The scope page states that neither PrincipalId nor CredentialId may contain the authenticating secret. The identifier of a key goes in the bill; the key itself never does.

What is not in 1.5

The scope page lists several AI requests as not taken up for 1.5, including reasoning tokens, context caching, input modality, batch tiers and provisioned throughput. A SKU Price dataset and a set of AI billing worked examples were still in final review when the page was updated. The v1.5 milestone on GitHub showed 79 percent complete with 36 open items on November 2, 2026. Treat both lists as moving until ratification.

What you can build today on each cloud

FOCUS 1.5 standardizes where the caller key lives. It does not create the key. Each provider already lets you create one, in its own place. If you build that habit now, 1.5 becomes a column mapping, not a project.

AWS

Amazon Bedrock application inference profiles are profiles you create to track costs and model usage. You attach tags to a profile and pass its ARN to InvokeModel, Converse and the other invocation APIs. AWS announced cost allocation tags on inference profiles on November 1, 2024, so GenAI inference costs can be grouped by department, team or application. On the billing side, AWS Data Exports for FOCUS 1.2 became generally available on November 19, 2025. One profile per application is the closest thing to a PrincipalId you can create on AWS today.

Azure

Microsoft’s Foundry cost management guidance, updated October 22, 2026, says bills typically show separate meters for model input and output, and that you can analyze input, output and cache costs. You can filter by deployment tags and user-defined tags to split cost by model deployment. For models sold by Azure, including Azure OpenAI, project usage is automatically tagged with a project tag; that capability is marked preview. Cost Management exports offer a FOCUS cost and usage dataset.

For per-caller detail inside one deployment, the API Management llm-emit-token-metric policy sends token counts to Application Insights with dimensions such as User ID, Subscription ID and Product ID, plus up to five custom dimensions. It covers OpenAI Chat Completions and Responses, Anthropic Messages and Google Vertex AI APIs. Cached and reasoning token categories in these metrics are in preview. These are operational metrics, not billing records: use them to compute each caller’s share, then apply that share to billed cost.

Google Cloud

Google documents custom metadata labels that you add to generateContent and streamGenerateContent calls to organize calls and manage costs. A label per application or agent is the Google Cloud equivalent of the caller key. For FOCUS, Google offers a BigQuery view and Looker template for FOCUS 1.0 built on the Cloud Billing exports.

A real-world scenario

Consider a hypothetical retailer that runs three AI workloads on one model deployment: a customer support assistant, a product description generator and an internal coding agent. The monthly bill shows one large line. Finance wants chargeback by product line.

Today, the platform team gives each workload its own caller key: an inference profile, a tagged deployment, a gateway subscription or a request label, depending on the cloud. The support assistant turns out to be mostly cached input reads. The description generator is mostly output tokens. The coding agent sends long uncached prompts. Split by caller and by token type, the three have very different cost curves, and the fix for each is different: better caching for one, shorter outputs for another, prompt trimming for the third.

With FOCUS 1.5 data from a provider that populates the new fields, the same split comes from grouping on PrincipalId, TokenDirection and TokenCacheAction in one query that works across providers.

Where it is heading (analysis)

The following is analysis, not vendor or FinOps Foundation guidance.

Identity becomes the primary allocation key for AI. Tags fit long-lived resources. Model calls are short events made by applications and agents holding a credential. Over the next 6 to 18 months, expect FinOps teams to allocate AI spend by identity first and by tag second, which brings FinOps, identity and agent governance into the same conversation.

Adoption will be uneven through 2027. The model and token properties are recommended, and the requester columns are conditional. Some providers will populate them early, some partially and some not at all. Gateways and request labels will remain the bridge for at least a year.

The gaps will drive 1.6. Reasoning tokens, batch tiers and provisioned throughput were requested and not taken up for 1.5. Teams that run agents with heavy reasoning or batch workloads should expect to keep a local mapping for those dimensions after 1.5 ships.

What to do next

FinOps teams

• Build AI reports on FOCUS columns, not provider-native ones, so adopting 1.5 is a schema change.
• Add input, output and cached tokens as separate dimensions in unit economics wherever the export already separates them.
• Ask each AI vendor which FOCUS version it exports and when it will populate PrincipalId, CredentialId and the token properties.

Platform teams

• Give every application or agent its own caller key: an inference profile on AWS, a tagged deployment or gateway subscription on Azure, a request label on Google Cloud.
• If you run a shared gateway, emit token metrics per caller now and store them next to billing data.

Security and identity teams

• Retire shared AI keys. Issue one credential per workload and record its owner.
• Agree a naming convention for credential and principal identifiers that is safe to appear in billing data.

Sources

• FOCUS 1.5 Release Scope: Confirmed, In Review and Deferred (updated October 2026)
• FOCUS Specification 1.4
• FOCUS_Spec v1.5 milestone on GitHub
• Amazon Bedrock User Guide: inference profiles
• AWS: Amazon Bedrock announces support for cost allocation tags on inference profiles (November 1, 2024)
• AWS: AWS Data Exports for FOCUS 1.2 is now generally available (November 19, 2025)
• Microsoft Learn: plan and manage costs for Foundry (updated October 22, 2026)
• Microsoft Learn: API Management llm-emit-token-metric policy (updated September 15, 2026)
• Microsoft Learn: create and manage Cost Management exports
• Google Cloud: custom metadata labels
• Google Cloud and FOCUS

Last verified: November 2, 2026. Published ahead of the FOCUS 1.5 ratification, targeted for December 3, 2026. This article will be updated once the release is final.