How we put token counts into FOCUS 1.4 without waiting for 1.5

This article explains how that works, column by column, and why we did it this way.

What FOCUS is, briefly

FOCUS is the open standard for billing data, published by the FinOps Foundation. It gives cloud billing the same column names, units and definitions across providers, so costs from AWS, Azure and Google Cloud can be analysed together.

The current version is FOCUS 1.4, ratified on 4 June 2026. The next one, 1.5, is planned to add native support for AI token usage.

Why we didn't wait for 1.5

FOCUS 1.5 is scheduled to be ratified on 3 December 2026 and announced at the FinOps Foundation's December Virtual Summit. That's a long time for a team to wait when its AI bill is growing now.

But the bigger reason is something the FOCUS project says itself, on its own 1.5 planning page: the gap isn't the schema. FOCUS already has the columns to carry token usage. The real problem is that nobody agreed how to use those columns for AI billing, so every vendor's data ends up normalised differently.

So we didn't need new columns. We needed to use the existing ones consistently.

Why we didn't use the draft 1.5 names

A draft is a draft. Column names can change between a working draft and the ratified version. If we had adopted draft 1.5 names and they changed in December, every customer's data would need renaming, and every query and report built on it would break.

Using the columns that are already ratified in 1.4 avoids that. They're stable, they're documented, and any tool that reads FOCUS 1.4 can already read them.

How a token becomes a FOCUS row

AI models charge for different types of token at different prices. Input usually costs less than output. Cached tokens are usually much cheaper. So we write each type of token as a separate usage row.

In each row:

• SkuMeter says which type of token it is. The five values are Input Tokens, Output Tokens, Cache Read Tokens, Cache Creation Tokens and Reasoning Tokens.
• PricingQuantity is the number of tokens.
• ListCost is calculated from the vendor's published price list.

So one hour of usage from one key and one model can produce up to five rows, one for each token type that was used.

This is the structure, simplified:

Keeping billed cost and list cost apart

A gateway already knows what it charged you. That's the billed cost. We also calculate a list cost for each token type from the vendor's price list.

If both went on the same rows, you'd count the money twice. So the gateway's billed cost goes on its own row, labelled Requests, exactly as the gateway reported it. The token rows carry list cost. Billed and list are never mixed on the same row.

This matters when you add things up. You can total the billed cost to see what you actually paid, or look at list cost by token type to see where the money went, without one distorting the other.

Where the extra fields go

FOCUS has a rule for information that isn't part of the standard: custom columns must start with x_. The specification gives the reason itself. The prefix keeps custom columns apart from FOCUS columns, so they can't clash with a column FOCUS adds in a future release. That's the same reason we didn't use draft 1.5 names. We follow the rule, including its naming style.

• x_GatewaySourceId says which gateway the row came from.
• x_SourceDimensions holds the gateway's own fields, like a LiteLLM team id, a Helicone user id or custom tags. This is what lets you split costs by team.
• x_UnpricedTokens records tokens we couldn't match to a price.

Because they follow the x_ rule, any FOCUS tool will read these columns without confusing them for standard ones.

Cloud data in 1.2, AI data in 1.4

AWS and Microsoft currently publish their billing exports in FOCUS 1.2. We write AI usage in 1.4. So one data lake can hold both.

That works because FOCUS is built to grow by adding, not by breaking. FOCUS 1.4 made no incompatible changes for existing implementations. Newer versions add columns on top of older ones, so cloud rows from 1.2 and AI rows from 1.4 can be queried together.

What about Amazon Bedrock

Amazon Bedrock is already billed in tokens on the AWS bill. Each Bedrock line has a meter that says input or output tokens, and a quantity that is the token count. For models sold through AWS Marketplace, that quantity is in millions of tokens. For AWS's own models, it's in thousands.

We convert those into token counts per model, account, region and hour, in the same row structure as gateway data. The one difference is that the Bedrock bill only has input and output tokens. It doesn't separate cache or reasoning tokens, so those rows don't appear for Bedrock.

What happens when FOCUS 1.5 arrives

FOCUS 1.5 is scoped to show AI model identity and token usage, meaning input and output tokens, in the Cost and Usage dataset, with worked examples for AI billing.

Two things about that are worth knowing.

Cached tokens may not be in it. Separating cached from fresh tokens is listed as a stretch goal for 1.5, not a confirmed part of it. Glassity already reports Cache Read and Cache Creation tokens separately, and reasoning tokens too. So on cache and reasoning, Glassity's data carries more detail than 1.5 is guaranteed to.

We'll map to 1.5 when it's ratified, not before. Because our data already sits in standard 1.4 columns, moving to 1.5 should be a mapping step rather than a rebuild. We'll adopt the ratified names once they are final.

Ernesto Suarez, Glassity's CEO, sits on the FOCUS working group, so we're following the 1.5 work closely as it happens.

Querying the data

Every night, this data is written into the same data lake as your cloud billing data. Two tools can query it.

The Glassity Agent answers questions in plain language, like "which model used the most reasoning tokens last month?"

Glassity's open-source FOCUS MCP server lets AI assistants like Claude query the same data. It reads every column, including the token rows and the x_ columns.

This is different from the FOCUS project's own MCP server, which has a similar name. That one answers questions about the FOCUS specification itself, like what a column means. Glassity's answers questions about your billing data. They do different jobs, and they work well side by side.