State of FinOps 2026: 98% of Teams Manage AI Spend, Tools Stop at the API Key

The FinOps Foundation's State of FinOps 2026 report says 98% of FinOps teams now manage AI spend, up from 63% in 2025 and 31% in 2024. That headline rests on 632 answers to a question that mixes what teams manage today with what they expect to manage within 12 months. Read the methodology, then read the vendor documentation, and a narrower picture appears. FinOps teams own AI spend on paper. Their cloud cost management tools see tokens by API key, GPUs by reservation, and agent runs not at all.

Who this is for: the head of a FinOps or platform team who has just been handed AI spend and needs a working allocation model, not a market overview. The short answer: the survey is right that ownership has moved to FinOps, and wrong if you read it as proof that the tooling has caught up. It has not, and the gaps are specific enough to plan around.

What the State of FinOps 2026 survey actually found

The State of FinOps is the FinOps Foundation's annual practitioner survey, run every year since 2020. The 2026 edition is the sixth. It was published on 19 February 2026 with 1,192 respondents, and the Foundation released further detail at FinOps X in June.

The headline is scope expansion. FinOps began as the discipline of managing public cloud bills. The 2026 report shows teams absorbing almost every other kind of technology spend at the same time. The Foundation even changed its mission line from managing "the Value of Cloud" to managing "the Value of Technology", according to the Linux Foundation's release.

Source: FinOps Foundation, data.finops.org, chart text retrieved 30 October 2026. The question covers areas managed "today and in the next 12 months", and the report shows one combined figure per area rather than separate current and planned bars.

AI is the fastest-moving line in the survey

AI moved 35 points in a year, more than any other category. Over two years it went from 31% to 98%, roughly a tripling.

AI bills arrived through several doors at once: API invoices from model providers, GPU instances on the cloud bill, and AI features bundled into SaaS renewals. Finance needed one team to own the total, and FinOps already owned the cloud bill. Ownership followed the invoice.

The report says 78% of FinOps practices now report into the CTO or CIO organisation, while reporting to the CFO fell to 8%. That matters for AI. A team that reports to engineering has a better chance of getting a request ID added to every model call, which is where most of the gaps in this post get closed.

The sample behind the 98% figure

A survey figure is only as useful as its denominator. The State of FinOps is more transparent than most vendor surveys, because it prints an N under every chart.

Different charts, different denominators

The report has 1,192 respondents. The scope chart that produces the 98% figure carries N=632. A separate AI spend chart carries N=693, the AI challenges chart N=649, and the leadership chart N=523. So roughly 53% of respondents answered the question behind the headline.

That is normal survey behaviour, and it still matters. If the people who skipped were disproportionately those whose teams do not touch AI, the true figure is lower than 98%. The report does not say who skipped.

The respondent mix leans large and global. Per the report, 47% came from large enterprises with 10,000 or more employees, 33% from enterprises with 1,000 to 9,999, and 20% from organisations under 1,000. By region, 35% were in Europe, the Middle East and Africa, 34% in North America, 16% in Asia Pacific and 15% in South and Central America.

This is a sample of people who identify as FinOps practitioners and who engage with the Foundation. It is not a random sample of companies. Companies that have no FinOps function at all are, by construction, absent. That makes the 98% a statement about mature FinOps teams, not about the market.

What the report does not disclose

Neither the report page nor the press release states fieldwork dates, sampling method or weighting. Neither shows the 2024 or 2025 question wording, so we cannot confirm the three years asked the same thing. The report also contains two different baselines for the same executive influence comparison: one section gives 53% versus 24% for cloud service selection, another gives 53% versus 12%. Our view: the survey is a good signal of direction and a weak instrument for precise levels. We would quote "nearly all FinOps teams now own AI spend" and would not build a forecast on the exact 98%.

What FinOps teams say they need for AI spend

The more useful parts of the State of FinOps 2026 are the questions about difficulty, not adoption. They describe a function that owns AI spend and cannot yet see it clearly.

On challenges, the report lists three for AI specifically. Visibility, because "pricing models vary widely across providers and services". Allocation to business units, which it calls "harder than traditional infrastructure". And value, because AI investments "are often exploratory, making returns hard to define early". The chart (N=649) is multi-select, and the page does not print percentages for each item.

The tooling question is sharper. Asked which features do not exist today, respondents put three at the top, in this order:

1. Granular monitoring of AI spend, covering tokens, LLM requests and GPU utilisation.
2. Shift-left, pre-deployment architecture costing.
3. A single pane of glass across different kinds of technology spend.

AI cost management is also the most wanted skillset across organisations of every size (N=695). And the report concedes that measuring shift-left work "remains one of the discipline's most important unsolved challenges".

Practitioners are telling the vendor market that the AI line on their bill is a black box. The rest of this post tests that against what the tools actually document.

Token cost management: what AI cost management tools see

For API-based AI, the source of truth is the model provider's own billing data. Every FinOps platform that covers OpenAI or Anthropic reads it through an admin-level API. So the provider's API sets a ceiling on what any downstream tool can show you.

The provider feed sets the ceiling

Anthropic's Usage and Cost API documentation is a good example because it is explicit. The usage endpoint reports uncached input, cached input, cache creation and output tokens. It can bucket them by minute, hour or day, and group them by API key, workspace, model and service tier. Usage data typically appears within 5 minutes.

The cost endpoint is coarser. Costs come in USD at daily granularity only, grouped by workspace or line-item description. Priority Tier costs are excluded from the cost endpoint entirely and must be tracked through usage. The documentation now labels this API legacy and points new integrations at a newer analytics API.

That shape suits a provider, not a FinOps team. Tokens are attributed to API keys and workspaces, which are access-control objects. They are not products, customers or tasks.

The cost platforms we checked all start from that feed. Vantage's Anthropic integration, launched in September 2025, reads only the Usage and Cost endpoint through an admin key and refreshes daily. It maps workspace to account, model to service and token type to subcategory, and tags each line with the API key ID. It does not cover Anthropic models consumed through Bedrock.

CloudZero's documentation describes two Anthropic connections: one for the API through the Usage and Cost API, and one for Claude Enterprise seats through an analytics API that breaks cost down per user. Costs appear within 24 hours, and Enterprise data is unavailable before 1 January 2026. Datadog's SaaS cost documentation lists both OpenAI and Anthropic and notes that OpenAI project-scoped keys cannot collect cost data, so an organisation admin key is required.

The value these platforms add is consolidation, and it is real. You get Anthropic, OpenAI and the cloud bill in one place, with your own tags and dashboards. What they cannot add is a dimension the provider never emitted. If the feed says API key, the platform says API key. This is the same reason falling token prices still produce rising AI bills: the unit you can see is not the unit that drives volume.

Cloud-hosted models follow the cloud bill's rules

Models consumed through a hyperscaler land on the cloud bill instead. On AWS, the documented method is an application inference profile per team or application, tagged and passed as the model ID. AWS's August 2026 architecture post notes there is no extra charge for this, that tags are case-sensitive, and that tagged costs take 24 to 48 hours to appear after activation. It also means attribution is only as granular as the number of profiles your engineers agree to create and use.

GPU cost allocation stops at the reservation

Self-hosted and fine-tuned models run on GPUs, and GPU cost is where the survey's request for "GPU utilisation" bites hardest. Allocation and utilisation are different questions. Most tooling answers the first.

How the AWS EKS method works

In September 2025 AWS extended split cost allocation data for EKS to NVIDIA and AMD GPUs, Trainium and Inferentia. It writes pod-level accelerator, CPU and memory records into the cost and usage report. AWS's accompanying blog says it uses the greater of reservation and usage to decide what each pod consumed, weights GPU against CPU and memory at 9:1, and redistributes unused instance cost proportionally across the pods.

That last step is the one to understand. A team whose pods reserve most of a GPU node, and leave much of it idle, does not see an idle line. The idle portion is spread back across the pods on that node. The bill balances, and the waste disappears into team totals.

For chargeback, redistribution is defensible. Someone has to pay for the node. For optimisation it is the opposite of what you want. GPU instances are the most expensive line most cloud teams have, and idle capacity is the first number a FinOps lead needs. The economics of that are covered in the GPU break-even utilisation model.

Utilisation, in the sense of how busy the accelerator actually was, comes from monitoring telemetry, not billing data. AWS's blog does not define how it measures GPU usage. Our recommendation is blunt: treat billing-derived GPU allocation as a chargeback tool and build utilisation reporting separately, from your observability stack, joined on node and pod.

Agent cost attribution is the gap no FinOps tool closes yet

Agents are where the gap becomes structural. An agent run is a sequence: several model calls, retries, tool calls, retrieval queries, perhaps a sub-agent. It can cross two providers and a vector database in under a minute. The unit a business cares about is the completed task, such as a resolved ticket or a reviewed contract.

None of the billing feeds above carries that unit. Provider cost endpoints report by key and day. Cloud bills report by tag and hour. Nothing in the documentation we read for Vantage, CloudZero, Datadog or AWS describes a native cost-per-agent-run metric. The FinOps Foundation's own FinOps X agenda included a session on full-stack AI cost attribution that describes the agent layer, cost per run and cost per resolved task, as the goal. A goal is not a shipped feature.

Where the data actually lives

Per-run cost exists only where per-run telemetry exists. That means the application's own logging or an LLM observability tool that traces each call. The tracing tools compared in our LangSmith, Braintrust and Arize review record token counts per span. Multiply those by a rate card and you have an estimated cost per run.

The word "estimated" is doing work. Trace-based cost will not reconcile exactly with the invoice. Cache discounts, batch rates, credits and committed-use pricing all sit between token counts and the final bill. Vendors pricing per task make this harder still, as the comparison of agent task meters across vendors shows.

FOCUS, the FinOps Foundation's open billing data specification, is the place to watch. Its 1.5 release scope page, updated October 2026, lists 1.4 as current and targets ratification of 1.5 on 3 December 2026. Working drafts add model identity columns, token direction (input or output) and token cache action. Drafts also add principal and credential identifiers, which would let a bill say which identity made a call. FOCUS has carried token counts since 1.0, per the same page.

That is genuine progress for tokens and for attributing spend to non-human identities. It still stops short of a task or run identifier. Until something carries that ID from the application into the bill, agent cost will be a join your team builds, not a column you download.

The coverage map for AI cost management tools

One pattern holds across every category. Tokens are covered at the key level. GPUs are covered at the reservation level. Agents are not covered by billing tools at all.

Compiled by Zan Digital from vendor and standards documentation retrieved October 2026. "Not documented" means the pages we read did not describe the capability, not that a vendor has confirmed its absence. Vendors ship monthly, so re-check before buying.

What that means for buying finops tools

If you are evaluating FinOps tools for AI, the demo will show a dashboard of model spend by team. Ask how "team" was derived. In most setups it is a mapping from API keys or workspaces that someone maintains by hand. That mapping is the real product, and it decays every time an engineer creates a new key.

We would buy a consolidation platform for the cloud and provider bills, and we would not expect it to answer cost per task. That answer comes from your own telemetry. The vendor that makes it easy to import your trace-level cost and reconcile it against the invoice is the one worth paying a premium for. Few document that today.

Where this argument is weakest

Three objections deserve a straight answer, and one of them partly wins.

First, documentation lags product. We mapped coverage from public documentation and vendor announcements, not from hands-on trials. A vendor may well support per-run attribution through custom tags or an ingestion API that its docs describe in general terms. "Not documented" in our table is a statement about what a buyer can verify before a sales call, and nothing stronger.

Second, key-level attribution can be good enough. A disciplined team that issues one API key per product feature, and one inference profile per application, gets usable allocation from today's tools. For many organisations, cost per feature per day answers the budget question. Cost per agent run is a precision problem that only matters once agent volume is large. That objection is fair.

Third, the survey may understate maturity rather than overstate it. Large enterprises are 47% of respondents and those teams average 8 to 10 practitioners at the $100 million spend level. Some of them will have built exactly the trace-to-invoice join described above, in-house. The survey cannot see internal tooling, and neither can we.

What survives all three: the most-requested feature in the 2026 survey is granular AI spend monitoring. Practitioners would not rank first a capability they already have.

Frequently asked questions

Where to start with AI spend this week

Pull a list of every active API key and inference profile across your AI providers, and write the owner and product feature next to each one. Any key you cannot assign is spend you cannot allocate, and that count is your honest baseline for AI visibility. It is also the number to bring to any AI spend forecasting exercise, because a forecast built on unassigned spend inherits the gap.

Then ask your engineering lead for one change: a run ID attached to every model call an agent makes, logged with the token counts. It costs a sprint at most. It is the only route to cost per task that exists today, and it will still be needed after FOCUS 1.5 ships.

Related reading