vibescoder
cd ..

Thursday Thoughts: FOCUS and the True Cost of a Token

·12 min read
aiagentscloud-nativehomelabfuture-of-coding

By day, I run a software company. That means my professional and personal lives intersect a lot. This week was one of those moments.

My Finance team was presenting a case to join the Tokenomics Foundation and a request to implement the FOCUS spec in both our internal systems and external product. I was vaguely familiar with both, but felt much smarter after a 30-minute debate.

But I can't stop there. I need to think about how this will affect the industry, employees, and — well — me.

I keep coming back to the cloud-native analogy for AI, and this week it clicked again in a place I wasn't expecting: FinOps.

On June 3rd, the Linux Foundation announced the intent to launch the Tokenomics Foundation, a new body dedicated to open standards for AI cost management, in close partnership with the FinOps Foundation. The first concrete deliverable is extending FOCUS — the FinOps Open Cost and Usage Specification, the schema that already normalizes cloud billing across AWS, Azure, and GCP — to cover token-based AI spend. Twelve organizations, including Google Cloud, Microsoft, Oracle, Salesforce, SAP, and JPMorgan Chase, are already backing it.

Here's why that matters to me, and why I think it should matter to you even if you've never opened a FinOps dashboard in your life.

We Took a Decade to Get Serious About Cloud Cost. We Don't Get That Long This Time.

The cloud era ran for years before "FinOps" became a real discipline with real standards. Chargeback and showback were ad hoc. Every cloud provider invented its own billing schema, and practitioners built bespoke ETL pipelines to make AWS, Azure, and GCP cost data speak the same language. FOCUS didn't formally exist as a Linux Foundation project until January 2023 — more than fifteen years after AWS launched EC2. We built the discipline of consumption-based cost management after consumption-based cost had already spiraled out of institutional control, and I've written before about how Anthropic is running a version of the exact same AWS-shaped playbook, just at a pace that makes the cloud era look slow.

Token-based AI spend is following the exact same consumption-based cost curve, except compressed. Global token usage is projected to grow 24x between 2026 and 2030, hitting 120 quadrillion tokens per month.

Bar chart showing global token usage growing 24x from a derived 2026 baseline of 5 quadrillion tokens per month to a projected 120 quadrillion tokens per month by 2030
Bar chart showing global token usage growing 24x from a derived 2026 baseline of 5 quadrillion tokens per month to a projected 120 quadrillion tokens per month by 2030

Chart: The Vibe Coder. 2030 figure and 24x growth multiple per Goldman Sachs research, as cited by It's FOSS; the 2026 baseline is derived by simple division and wasn't independently reported.

And unlike a vCPU-hour, which is a stable, well-understood unit, a token is not a fixed unit at all — different models tokenize the same text differently, and pricing, context windows, and caching behavior shift under you without notice. The fact that the industry is standing up FOCUS-for-AI now, three years into the LLM API era rather than fifteen, is a genuinely good sign. It means we're applying a lesson instead of relearning it from scratch. That's the whole thesis of this blog in miniature: don't lift-and-shift the old playbook onto AI, but do keep the parts of the old playbook that were hard-won and correct. Consumption-based cost governance is one of those parts.

Why This Actually Matters to Vibe Coders, Not Just FinOps Practitioners

I don't write this blog for people managing million-dollar cloud bills. I write it because I think every knowledge worker is about to become a vibe coder, the same way every knowledge worker is already a spreadsheet user or a slide-deck builder. Building an internal tool, a workflow automation, or a small app is going to be a universal white-collar skill within a few years, not a specialist one. That's the premise this whole blog runs on.

Which means the economics conversation happening in FinOps circles right now isn't going to stay contained to platform teams and CFOs. It's coming for every person who opens an agent chat and says "build me a dashboard." Once vibe coding is universal, token consumption becomes as distributed, as invisible, and as easy to blow past a budget on as cloud spend was in 2015 — except instead of one platform team provisioning EC2 instances, it's every employee with an agent tab open. The State of FinOps 2026 survey found AI has become a mainstream technology investment, with 98% of FinOps teams now managing AI spend, up from just 31% two years ago. That number is going to keep climbing precisely because the people generating the spend are no longer engineers alone.

The practical question for a vibe coder — hobbyist or enterprise employee alike — isn't "what does FOCUS mean for finance." It's "will my organization eventually meter me the way it metered a Kubernetes namespace." I think the answer is yes, and I think it should be, because the alternative is nobody knowing what any of this actually costs until the invoice arrives.

What FOCUS Actually Is, and Isn't

FOCUS is not a logging or telemetry standard. It's a billing schema — closer to a standardized invoice format than to an observability trace. It defines a common schema for technology cost and usage data across cloud, SaaS, data center, and other technology categories, establishing a consistent, vendor-neutral vocabulary for billing and usage data. A FOCUS dataset is a table of charges, where each row represents one charge, and every column has a defined name, data type, and meaning set by the specification, so the column means the same thing regardless of which provider produced the row.

Concretely, it ships as CSV or Parquet exports (AWS's CUR 2.0 can output FOCUS 1.2-formatted Parquet to S3), normative language follows RFC 2119/8174 (MUST/SHOULD/MAY), and providers can extend it with x_-prefixed columns for proprietary detail without breaking the shared schema. There's even an open-source validator that checks a dataset against the spec version by version.

(One housekeeping note: the FOCUS and FinOps Foundation logos are registered trademarks, so rather than reproduce them here, I'm linking straight to the FOCUS brand site and the FinOps Foundation media page if you want the official marks.)

The Evolution, and Where 1.4 Landed

FOCUS has moved fast for a standards body:

  • v1.0 (2024): established the core schema — BilledCost, EffectiveCost, ConsumedQuantity — for Cloud Service Provider billing.
  • v1.1 (Nov 2024): added invoice reconciliation and unit-cost/density metrics (cost-per-GB, cost-per-request).
  • v1.2 (May 2025): unified Cloud + SaaS + PaaS reporting into one schema, and — notably for this post — introduced the first language around virtual currency and token purchase pattern analysis.
  • v1.3 (Dec 2025): added a dedicated Contract Commitment dataset and, critically, first-class shared-cost allocation fields — which resource was shared, who consumed it, and what method split the cost.
  • v1.4 (ratified June 4, 2026, at FinOps X): the current release. It adds 2 datasets, 47 columns, 6 attributes, 17 glossary entries, and 2 supported features, headlined by new Invoice Detail and Billing Period datasets for reconciling usage straight to invoices, and Service Provider vs. Host Provider columns that separate who sold you the resource from who's actually running it underneath, disambiguating reseller relationships.

Timeline showing five FOCUS specification releases from v1.0 in 2024 through v1.4 ratified June 4, 2026, each annotated with its key additions
Timeline showing five FOCUS specification releases from v1.0 in 2024 through v1.4 ratified June 4, 2026, each annotated with its key additions

Chart: The Vibe Coder. Ratification dates and release details per the FOCUS Specification changelog, licensed CC-BY-4.0.

The AI-specific columns riding on top of that 1.4 release are the ones that matter most here: ConsumedQuantity, ConsumedUnit, HostProviderName, and the x_InputTokens / x_OutputTokens / x_CachedTokens splits the spec introduced specifically for AI workloads. That's the schema-level answer to "how much did this model call actually cost, and for what."

What FOCUS 1.4 Gets Right for AI Consumption

If you're buying tokens from a frontier lab or a hyperscaler's managed AI service, FOCUS today gives you real, standardized ground to stand on:

Where It Still Falls Short for Self-Hosting

This is the part that matters if you run your own models, and it's the part that isn't solved yet.

If you self-host, there's no token to bill in the first place. When you run an open-weight model on your own GPUs, cost is expressed entirely in compute — GPU instance hours, storage, and networking — because there is no per-token charge. FOCUS handles that side fine; a GPU instance is just another compute row with a BilledCost and ConsumedQuantity in GPU-hours, same as any VM. What FOCUS does not give you is a bridge back from that GPU-hour to a per-token or per-request cost. You have to build that join yourself, against your own inference telemetry.

Token economics that only counts tokens is a partial view. The FinOps Foundation says this plainly: beneath every token is a chain of physical and architectural decisions that determine what the token costs to produce, and for self-hosted deployments that means the capital cost of facilities, power, and cooling, with industry estimates placing next-generation AI data center construction at fifteen to twenty million dollars per megawatt of capacity. None of that shows up as a FOCUS column today. There's no x_PowerDrawWatts, no PUE field, no hardware depreciation schedule. The spec's amortization machinery could carry that eventually — it already amortizes commitments — but nobody has defined the columns yet.

The frontier work is still aimed at the wrong side of the ledger. FOCUS 1.5 is slated to break down AI spend by token type and workload, giving practitioners the granularity to tie inference costs back to the teams consuming them — but that's still describing metered consumption, not manufactured tokens. Jensen Huang's "AI factory" framing is the more honest lens for self-hosters: electricity and silicon enter the factory, tokens emerge, and the real unit-economics question is revenue (or value) per megawatt, not price per API call. FOCUS hasn't gone there yet.

Cardinality is a real, admitted problem. Even on the consumption side, FOCUS contributors are candid that the harder frontier is AI token economics, because measuring the cost of inference requires visibility down to the per-user, per-session, and per-request level, and it could end up being that a non-trivial percentage of your cost is having to be attributed to just getting your data and putting it through a pipeline. If that's true at hyperscaler scale, it's just as true, proportionally, on a single GPU box in someone's closet.

What We're Going to Try on the Homelab

Yes, running a FinOps billing spec against a single RTX 5090 is a little absurd on its face. Nobody needs a standardized multi-cloud invoice schema to know what one GPU costs. But that's exactly why I want to try it. Homelab-scale is the cleanest possible environment to see whether the discipline holds up when you strip away all the enterprise noise — no shared cost pools, no negotiated discounts, no thousand-account org structure. Just one box, one power meter, and a request log.

The plan is to try to build a real, if tiny, FOCUS-shaped dataset for the homelab: BilledCost derived from wall-clock power draw at the outlet times our electricity rate, ConsumedQuantity in tokens/sec pulled from llama.cpp's own metrics, and a hand-rolled x_PowerDrawWatts column FOCUS doesn't define yet, joined against the model and quant we were running at the time (our daily driver is still Qwen 3.5 35B-A3B at Q4_K_XL, 22 GB of weights, 200+ tok/s on the 5090). If it works, it becomes the smallest possible proof that the "AI factory" framing scales down as cleanly as it scales up — that the true cost of a token is never just the API price, it's power and silicon showing up as a line item, whether that line item is a hyperscaler's data center or a workstation under a desk.

By the Numbers

Comments