Introducing TokenIQ: FinOps for AI

Alan Hand
June 8, 2026
8 min read

In May 2026, Uber CEO Dara Khosrowshahi told investors the company had "blew through our AI budget in a quarter, for the whole year essentially." Uber's CTO added that spending on Claude Code alone had run past internal expectations. The response was a hard cap: every employee, $1,500 per month, per AI coding tool.

A few weeks earlier, an internal Meta dashboard nicknamed Claudeonomics had leaked. It ranked the company's roughly 85,000 employees by token consumption. Total usage cleared 60 trillion tokens in a 30-day window. Neither Mark Zuckerberg nor CTO Andrew Bosworth made the top 250. Bosworth defended the spending pattern publicly, saying his best engineer was burning the equivalent of his salary in tokens, and was "5x to 10x more productive."

These are not edge cases. They are the canary on the 2026 enterprise AI cycle. Combined 2026 capital expenditure across Meta, Amazon, Microsoft, and Alphabet is already pushing $700 billion, with some Wall Street projections clearing $1 trillion in 2027. The bills are real. The question every CFO is now asking engineering and FinOps teams to answer is "what are we getting for it?" In most organizations, the answer is some combination of anecdote, vendor case study, and engineering optimism. None of it survives a serious review.

This is a familiar trajectory. Cloud spend in the early 2010s looked similar: opaque vendor bills, attribution that took weeks to assemble, capacity decisions made on intuition, finance and engineering blaming each other for budget surprises. The discipline that emerged in response was FinOps: visibility, attribution, accountability, and a cultural shift that treated cloud cost as a first-class engineering concern rather than a quarterly finance puzzle.

The AI cost story is shaped by the same forces, but it is not the same problem. Tokens are not instance-hours. LLM calls have no idle utilization to right-size. The value side of the equation involves outputs whose quality is itself fuzzy. The optimization levers (model routing, semantic caching, budget-aware policy) have no clean analog in compute orchestration. The principles that built FinOps carry over directly, and the tools have to be tailor-made for the medium they operate in.

Today we are launching TokenIQ, a new product built specifically to close that gap. TokenIQ gives FinOps and engineering teams unified governance across AI providers, granular cost attribution, productivity correlation, and automated optimization, anchored on a defensible new metric called AIR (AI Return).

Why TokenIQ now

Every conversation we have had with FinOps leaders in 2026 lands on the same observation. Cloud costs were the dominant problem of the last decade while AI costs are the dominant problem of this one.

This is not just a budget issue. Cloud overrun in 2014 was painful but tractable. You could right-size a fleet. You could commit to Reserved Instances. You could look at the bill and see clearly what was driving it. AI overrun in 2026 is different in kind. The bill arrives unstructured. Tokens, requests, and inference time aggregate into one provider line item per vendor. Whose tokens those were is anyone's guess. Whether they delivered any value is an even harder question.

Teams that spent years building muscle around Spot adoption, Reserved Instance planning, and Kubernetes right-sizing are now staring at LLM bills that grow unpredictably, do not attach cleanly to anything in particular, and resist the tools the FinOps community built for compute.

Bolting AI cost discipline onto an existing FinOps practice does not work, because LLM workloads behave nothing like EC2 instances. They have no idle time to recover. They have no obvious unit of work to right-size against. They route across multiple providers based on prompt, context, and policy, in ways no spreadsheet can keep up with. They need their own optimization layer, one that understands tokens, providers, prompts, and outcomes the way a Spot orchestrator understands instance families and availability zones.

That layer is TokenIQ.

The Gateway: the substrate

Most enterprises end up with four or five LLM providers in production within a year of starting. OpenAI for one team, Anthropic for another, a vendor-of-the-month for some experimental work, plus whatever the security team approved last quarter. Each provider brings its own API, its own quotas, its own observability surface, and its own risk profile. Each one is a separate auth boundary, a separate SDK to maintain, a separate vendor relationship to manage.

TokenIQ sits in front of all of them as a single intelligent gateway with unified access, policy-based routing, centralized governance, prompt caching, and per-request telemetry. The gateway is the substrate everything else in TokenIQ runs on top of: without per-request telemetry there is nothing to attribute, nothing to compute AIR against, and nothing to optimize.

The gateway ships in three deployment models so you can adopt TokenIQ in whatever way matches your existing posture.

Bring your own gateway

If you are already running a production gateway such as LiteLLM or BitFrost, TokenIQ integrates with it through plugins. You keep your existing infrastructure and add the intelligence layer on top.

Managed service

Want to run your LLM gateway inside your own cloud account but do not have one yet? TokenIQ makes it straightforward to stand up a production-grade enterprise LLM gateway in minutes, and Xosphere handles ongoing maintenance. Think RDS, but for your gateway.

SaaS

Prefer to skip the operational footprint entirely? Xosphere runs the gateway for you, fully managed.

The result is enterprise AI you can govern at scale without locking yourself to one vendor or asking every developer to learn five SDKs.

The four phases

On top of the gateway, TokenIQ operates as a four-phase pipeline: attribute, estimate, calculate AIR, optimize. Each phase produces the inputs the next phase needs, and the last one feeds back into the first.

Phase 1: Attribute

Per-user and per-team token attribution is already a solved problem at the gateway layer. Every serious LLM gateway (LiteLLM, BitFrost, etc.) can tag requests with a user identity and roll spend up to a team or department. If that is all you need, you do not need TokenIQ.

The actual gap is one layer deeper. Knowing that the platform team spent $48,000 on Claude last month tells you which budget to charge. It does not tell you whether that spend produced anything. The unit that matters to the rest of the business is not the team; it is the business outcome the team produces. Cost per commit. Cost per pull request. Cost per code review. Cost per shipped feature. Cost per active user. Cost per resolved support ticket. Cost per customer interaction. Cost per revenue-generating workflow.

TokenIQ rolls token spend up into those units. The same underlying telemetry that today produces a per-team line item gets joined against the engineering, product, and support systems that already track outcomes (GitHub or GitLab for code activity, Jira or Linear for tickets, the data warehouse for business events), and emerges as the metric each audience already uses to make decisions. Engineering leadership reads cost per PR. Product leadership reads cost per shipped feature. Support leadership reads cost per resolved ticket. Finance and the executive team read cost per revenue-generating workflow.

That is the attribution finance has been asking for and gateways have not been able to produce.

Phase 2: Estimate time and effort saved

Cost without value is half a metric. Phase 2 is where TokenIQ computes the value side of the equation: estimated time and effort saved per business outcome, anchored in measurable engineering signals rather than self-reported productivity gains.

TokenIQ correlates AI usage with the outcome metrics engineering organizations already track. DORA metrics like deployment frequency and lead time for changes. SPACE metrics for developer effectiveness, velocity, and quality. Custom organizational metrics where they exist.

The estimate is task-level. Bug fixes, feature ships, code reviews, and documentation each carry different time-saved values, because they actually do. The output is per-task average time saved, multiplied by actual task counts from the systems Phase 1 already joined against.

Phase 3: Calculate AIR

Phase 1 gives you cost. Phase 2 gives you estimated value. Phase 3 turns those into a single number: AIR (AI Return). The definition is straightforward: value created by AI, net of AI costs, divided by AI cost.

An AIR of 3.0 means every dollar of AI spend is producing three dollars of value, net of cost. An AIR below 1.0 means the program is losing money at the current configuration, which is information worth having early. AIR rolls up per workflow, per team, per product, or per stakeholder view, using the same attribution chain Phase 1 established.

We have written a separate post that walks through AIR in detail, including how to define the value-of-time variable, why most AI ROI calculations fail, and how to make the metric defensible at the task level. If you are working through the AIR computation specifically, that is the right place to start.

Phase 4: Optimize

Phases 1 through 3 are visibility. Phase 4 is action.

Once you can see AIR per workflow, TokenIQ closes the loop with several optimization levers:

• Intelligent model and provider selection. Routing each request to the model that produces an acceptable answer at the lowest cost, given the workload's quality requirements.
• Semantic caching. Recognizing when two requests are semantically equivalent even if their text differs, and serving cached responses where appropriate.
• Budget-aware routing. Enforcing per-team and per-workflow spend caps without hard-failing user requests.
• Continuous waste reduction. Surfacing the prompts, agents, and workflows where tokens are being burned with no corresponding AIR, and either optimizing them automatically or escalating them for human review.

The operator sets policy (which models are permitted, which spend caps apply, where humans need to be in the loop), and TokenIQ runs the execution continuously against that policy. The output of Phase 4 (lower cost on the same workflows, or higher value per dollar spent) feeds back into Phase 1's attribution data, restarting the cycle at a better operating point.

What we explicitly do not believe

Honest product announcements include the parts that complicate the pitch.

TokenIQ is not a replacement for human judgment about which AI workloads matter. The platform measures, attributes, and optimizes. It does not tell the product team whether building feature X with AI is a good idea. That decision still lives where it always lived.

TokenIQ is not a silver bullet for organizations whose AI strategy is itself the problem. Several teams we talked to were spending heavily on AI for workflows that did not deliver clear value. Better measurement will not save those workflows. It will just produce a precise number on a sub-1.0 AIR. The number itself is useful because it forces a different conversation than the one nobody is having today.

TokenIQ is not, today, the right fit for organizations using a single LLM provider with one workflow. The platform's value compounds with complexity. Single-team, single-provider deployments can probably get by with a spreadsheet, at least for now.

What we do believe is that the organizations that get AI cost discipline right in 2026 will compound their lead through 2027 and 2028, the same way the organizations that got cloud cost discipline right in the early 2010s compounded theirs.

Where TokenIQ sits in the Xosphere lineup

TokenIQ launches alongside our existing cloud cost optimization products under a single platform brand, Xosphere IQ. Customers will recognize the products that join it: SpotIQ is our autonomous Spot orchestration product, which you have known as Xosphere Instance Orchestrator for the past nine years; ClusterIQ is our Kubernetes optimization product, previously known as XoNodePools. These are the same products with the same functionality (no changes to install or runbooks). The new names fit the platform naming convention; the underlying software and your existing deployments are unchanged.

What is genuinely new is TokenIQ. Cloud cost optimization and AI cost optimization belong under the same roof, with the same posture of keeping customer data inside customer accounts.

Getting started

If you have been thinking about bringing AI cost discipline into your FinOps practice, this is the moment to talk. We are working with a small group of design partners through the rest of 2026 ahead of broader availability. TokenIQ deploys into your own cloud account, and your data stays inside your environment.

If that fits, get in touch.

What comes next

The four phases are the starting surface area. Over the coming year we expect to deepen each one: richer routing across more providers, deeper outcome correlation against more engineering and business metrics, additional optimization levers, and tighter integration with the AI provider ecosystem as it evolves. We will be writing about each phase as it ships, in this same blog.