AI and GPU Cost Tools in 2026: 8 Ranked by Where the Spend Escapes
FOCUS, Infracost, OpenCost, Kubecost, CAST AI, LiteLLM and more compared for token and GPU spend - including what FOCUS actually does for AI billing.
The classic FinOps stack was built for resources you provision. AI spend is consumption you cannot pre-provision, and that difference breaks most of the tooling assumptions underneath cost management.
A reserved instance is a commitment you make once and amortise. A token is a purchase made thousands of times a second by code you wrote last sprint. GPU capacity sits awkwardly between the two: provisioned like infrastructure, consumed like a utility, and priced like neither.
So rather than ranking tools by features, this guide maps them onto the three places AI spend actually escapes. Most teams instrument exactly one and are surprised by the other two.
| Leak point | What escapes | Tools |
|---|---|---|
| Before deploy | GPU capacity nobody costed | Infracost |
| Inside the cluster | Node cost nobody can attribute | OpenCost, Kubecost, CAST AI |
| At the API call | Token spend per feature | LiteLLM, Helicone, provider consoles |
| Across all three | A common data shape | FOCUS |
For the classic cloud-cost question - CloudHealth, Vantage, Kubecost as general platforms - our FinOps tool comparison covers that ground. This one is about the AI-shaped part.
1. FOCUS - a shape to normalise into, not an answer
Open specification. Free.
FOCUS is the FinOps Open Cost and Usage Specification, and 1.3 was ratified on 4 December 2025. It matters because it gives multi-cloud billing a common schema instead of four vendor dialects.
What it does for AI is more limited than most write-ups suggest. FOCUS has no AI-native columns. What it has are generic constructs - ConsumedQuantity, ConsumedUnit, PricingQuantity, PricingUnit, ServiceCategory - into which token consumption and image generation can be mapped. The gap has been worked examples rather than schema, and those examples are only now landing in the specification repository.
Use it as the normalising layer you land everything in. Do not expect it to allocate AI spend for you, and check what your provider’s export actually emits rather than what the current spec supports - adoption lags ratification by a lot.
2. Infracost - the only one that catches spend before it exists
Open source, with a commercial tier.
Infracost puts cloud cost estimates directly into pull requests for Terraform, which makes it the one tool here that prevents spend rather than reporting it. For GPU capacity that distinction is worth real money: an oversized node pool caught in review costs nothing, and the same pool caught on the invoice has already run for a month.
Two 2026 developments make it more relevant to AI work than it was. Infracost 2.0 refactored the codebase into focused repositories, and infracost/agent-skills plugs Infracost into Claude Code, Cursor and other AI coding agents so they reason about cloud costs and your FinOps policies while generating infrastructure code. That is a genuinely different control point: the cost guardrail moves from the reviewer to the thing writing the Terraform. Infracost has also shipped tooling aimed at modelling AI spend decisions before they are made.
Pick it when infrastructure is defined as code and GPU capacity is provisioned by engineers. It does nothing about token spend, which is a different leak.
3. OpenCost - vendor-neutral cluster allocation
CNCF project. Free, open source.
OpenCost allocates Kubernetes costs down to namespace, workload, label and team. In an AI context its value is answering which team spent that when several share a GPU node pool - the question that turns a large invoice line into an actionable one.
Pick it when you want allocation without a vendor relationship. Be warned that allocation quality is entirely a function of labelling discipline; unlabelled workloads produce a faithful report that your largest spender is default.
See OpenCost vs Kubecost for the direct comparison.
4. Kubecost - OpenCost plus the product around it
Commercial, with a free tier.
Kubecost builds on the same allocation model and adds the layer teams actually operate with: dashboards, alerting, savings recommendations, multi-cluster views and retention. For GPU-heavy clusters the recommendation engine is the differentiator, since idle GPU is the most expensive idle resource in a typical estate.
Pick it when you want allocation as a product rather than a component.
5. CAST AI - automated optimisation rather than reporting
Commercial.
CAST AI sits a step beyond reporting: it actively rightsizes and rebalances Kubernetes workloads, including moving between instance types and spot capacity. The pitch is that optimisation should be continuous and automatic rather than a quarterly review.
Pick it when you have accepted that manual rightsizing never happens and you would rather delegate it. Be deliberate about how much autonomy you grant it in a GPU context, where instance substitution has performance consequences a CPU workload would not notice.
See Kubecost vs CAST AI.
6. LiteLLM - token attribution at the gateway
Open source, with a commercial tier.
LiteLLM is a proxy across 100+ models that tracks spend for keys, users and teams. That gateway position is the whole argument: every call passes through, so attribution is structural rather than something each service has to remember to implement.
The alternative - instrumenting inside application code - fails in a predictable way. Every new service re-implements it, and the one that forgets is invisible in exactly the way that matters.
Pick it when more than one service calls models, which is nearly always by the second quarter. Make the API key the unit of accounting and the attribution question answers itself.
Our LLM API cost optimisation guide covers what to do once you can see the numbers.
7. Helicone - fast to adopt, uncertain ownership
Open source, commercial tier. Acquired by Mintlify in early 2026.
Helicone was historically the quickest of these to adopt: one header change on your OpenAI client and you get cost per request, model distribution and per-user breakdowns. It is a genuinely low-friction way to get from nothing to visibility.
The caveat is ownership. Helicone was acquired by Mintlify in early 2026, and the roadmap is less clear post-acquisition. If you already run it, nothing has broken. If you are choosing fresh, watch for announcements or prefer an option whose ownership is settled - the same judgement you would apply to any dependency after an acquisition.
8. Provider consoles - free, and not enough
Included with the account.
AWS Cost Explorer, Azure Cost Management and the OpenAI usage dashboard are free and are where everyone starts. They are also single-provider by construction, which is the problem: GPU spend is the easiest category to spread across vendors, with capacity rented from one neocloud, more from another, hyperscaler bursts for spillover and often a sovereign-region partner for regulated workloads.
Use them for the provider-specific detail nothing else has. Do not mistake four provider consoles for a cost management practice - that is the gap FOCUS exists to close.
Our OpenAI API cost optimisation post covers the provider-side levers.
Attribution before optimisation
The most common mistake in AI cost work is reaching for cheaper models and aggressive caching while still unable to say which feature, team or customer generated the spend.
Without attribution you cannot distinguish an expensive feature that earns its cost from one that does not, so every optimisation is a guess - and guesses in this domain tend to degrade the product to save money that was never the problem. In practice a large share of apparent overspend resolves to one runaway job, one un-cached hot path, or one team’s experiment left running, none of which are found by switching models.
Get attribution working at all three leak points, then optimise what the data points at. That sequence is also why our AI and GPU cost governance work builds per-team and per-feature attribution before proposing a single efficiency change, and why GPU cost governance is a policy problem as much as a tooling one.
If your cloud bill is now mostly AI and nobody can say whose, start there.
Frequently Asked Questions
Does FOCUS support AI and token billing?
Partly, and less directly than most write-ups imply. FOCUS has no AI-native columns. What it has are generic constructs - ConsumedQuantity, ConsumedUnit, PricingQuantity, PricingUnit, ServiceCategory - that token and generation billing can be mapped into. The gap has been worked examples rather than schema, and those are only now landing in the spec repository. So FOCUS gives you a common shape to normalise AI spend into; it does not hand you AI cost allocation out of the box, and anyone selling it as though it does is overstating.
What is the current FOCUS version?
FOCUS 1.3 was ratified by the FOCUS Steering Committee on 4 December 2025. Adoption lags ratification substantially - the version your cloud provider actually exports is often behind the current spec, so check what your billing export emits rather than what the spec supports. Treat any blog post quoting a version number as needing verification against focus.finops.org before you plan around it.
Where does AI spend actually escape?
Three distinct points, and most teams only instrument one. Before deploy, when someone provisions GPU capacity in Terraform that nobody costed - caught by shift-left tooling like Infracost. Inside the cluster, when GPU nodes are allocated to namespaces nobody can attribute - caught by OpenCost or Kubecost. At the API call, when token spend accumulates per feature with no attribution - caught at the gateway by LiteLLM or an observability layer. A tool covering one leak point tells you nothing about the other two.
Can Kubecost or OpenCost handle GPU allocation?
Yes, and this is where they earn their place in an AI stack rather than a generic one. Both allocate node costs to namespaces, workloads and labels, which is the only practical way to answer which team spent that when several teams share a GPU node pool. The caveat is that allocation is only as good as your labelling - if workloads are not labelled by team or product, the tool will faithfully report that an unlabelled namespace consumed most of your budget.
How do you track LLM token spend per team or feature?
At the gateway, not in the application. LiteLLM tracks spend for keys, users and teams across 100+ models and is the common answer because it attributes at the proxy layer, so every call is counted regardless of which service made it. Doing this inside application code means every new service re-implements it and one that forgets is invisible. Put the attribution boundary where calls must pass through, and make the key the unit of accounting.
Is Helicone still a safe choice for LLM cost tracking?
Approach with care. Helicone was acquired by Mintlify in early 2026, and the product roadmap is less clear post-acquisition. It was historically the fastest thing to set up - a single header change gives cost per request, model distribution and per-user breakdown. If you already run it, nothing has broken. If you are choosing fresh, watch for roadmap announcements before committing, or use a gateway-level option whose ownership is settled.
What is the single highest-leverage change for a team overspending on AI?
Attribution before optimisation. Most teams jump to cheaper models or aggressive caching while still unable to say which feature, team or customer generated the spend. Without attribution you cannot tell an expensive feature that earns its cost from one that does not, so every optimisation is a guess. Get per-team and per-feature attribution working first; the optimisation targets become obvious once you can see them, and half of them turn out to be one runaway job.
Complementary NomadX Services
Get Your FinOps Defect Score
Book a free 30-minute cloud cost review. We will identify your top three FinOps gaps and give you a preliminary Defect Score - no pitch, no obligation.
Talk to an Expert