← Agent Frameworks 🕐 25 min read
Agent Frameworks

FinOps Foundation AI Cost Management Standards (2026)

Summary · March 2026

The FinOps Foundation has made AI cost management its central 2025–2026 initiative.

The FinOps Foundation has made AI cost management its central 2025–2026 initiative. The FinOps for AI Working Group has published a three-paper research series, a comprehensive overview framework, and a four-level certification curriculum. FOCUS — the FinOps Open Cost and Usage Specification — reached versions 1.2 (May 2025) and 1.3 (December 2025), with dedicated AI/ML column support deferred to future versions but a clear extension path via the token-metered billing pattern already in use by Azure OpenAI and AWS Bedrock. The State of FinOps 2026 survey (n=~2,000+ practitioners) found that 98% of organizations now manage AI spend, yet fewer than 20% apply unit economics to it — a maturity gap that defines the Foundation’s near-term agenda.

1. FinOps for AI Working Group

Formation and Membership

The FinOps for AI Working Group was established in late 2024 and formalized its research output cadence through 2025. The group lists 28 contributors drawn from enterprise buyers, hyperscaler product teams, and consulting practices. Named organizational contributors include:

  • Hyperscalers / Cloud providers: Google, Amazon Web Services
  • Financial services: Wells Fargo, MetLife, Munich Re
  • Professional services: Accenture, EY, KPMG
  • Platform and tooling vendors: Coveo, OptimNow, NTT Data, RealCloud
  • Enterprise buyers: Wayfair, Superhuman, Trilogy

FinOps Foundation staff support: Vas Markanastasakis, Rob Martin, Andrew Nhem, Samantha White.

Published Deliverables

The working group has produced a sequential research series:

Paper 1 — “How to Forecast AI Services Costs in Cloud” (2024) Establishes baseline forecasting methodology for managed AI API services. Focuses on token-volume modeling, reserved vs. on-demand pricing comparison, and seasonality adjustments for chatbot and inference workloads.

Paper 2 — “Cost Estimation of AI Workloads” (Q1 2025) Provides a five-step application-centric cost estimation framework: (1) token-level transaction modeling, (2) prompt engineering optimization impact, (3) dedicated instance vs. per-token billing comparison, (4) quantization analysis, (5) fine-tuning cost-benefit assessment. Introduces the six-persona breakdown for cost responsibility (Senior Leader, Financial/FP&A, FinOps Lead, Engineer, Data Scientist, Procurement).

Paper 3 — “Effect of Optimization on AI Forecasting” (Q3 2025) Addresses how engineering optimizations — model selection, backend infrastructure changes, consumer-side prompt tuning — distort forecasts by reducing token consumption after budgets are set. Recommends financial investment analogies (scenario analysis, sensitivity ranges) rather than point estimates for AI budgets. Treats optimization as a deliberate financial lever, not an IT side effect.

Overview Framework — “FinOps for AI Overview” (Last updated February 2026) The capstone working group document. Synthesizes all prior papers into a unified framework covering: fundamentals of AI-driven cloud architecture, business value measurement across six pillars, cost management best practices, governance and organizational structures, the Crawl/Walk/Run maturity model, a ten-KPI library, and regulatory compliance considerations.

Supplementary Working Paper — “FinOps for AI: Tools and Services Considerations” (2025) Covers the pricing models of major AI API providers (OpenAI, Anthropic, Google, Cohere, Mistral) and infrastructure considerations for self-hosted models.

Case Study — Workday (July 2025) Demonstrates how Workday applies FinOps practices to AI consumption data and adjusts unit metrics to inform business decisions. Published as a practitioner case study on finops.org.

Working Paper — Kubernetes AI Optimization (October 2025) Explores elastic and efficient AI/ML on Kubernetes, scaling challenges through a FinOps lens, and proven orchestration patterns.

Working Paper — GenAI Capacity Models (February 2026) Analyzes capacity models (reserved throughput, provisioned capacity, spot) across AWS, GCP, and Azure — covering traffic shapes, spillover logic, and hidden costs under each model.

Deliverables Timeline

Date Deliverable
2024 Q4 User story collection; Paper 1 (Forecasting)
2025 Q1 Paper 2 (Cost Estimation)
2025 Q3 Paper 3 (Optimization/Forecasting); Workday case study
2025 Q3 Kubernetes AI optimization paper
2025 Q4 Token economics deep-dive (finops.org Insights series)
2026 Q1 GenAI Capacity Models paper; FinOps for AI Overview (final update)
2026 Q1 FinOps Certified: FinOps for AI exam availability

2. FOCUS Specification: 1.0 → 1.2 → 1.3 and AI/ML Implications

FOCUS Background

FOCUS (FinOps Open Cost and Usage Specification) is the Foundation’s open schema standard for billing data, maintained under the Linux Foundation. Its goal: one normalized dataset consumable across AWS, Azure, GCP, OCI, and SaaS providers without per-vendor translation. FOCUS defines columns (fields), their data types, allowed values, and whether they are required or conditional per provider type.

FOCUS 1.0 (June 2024 GA)

Established the core billing schema: ~40 columns covering resource identity, cost dimensions (billed cost, effective cost, list cost), pricing model, commitment discount tracking, and tags. AI/ML services were handled as generic compute/API rows — no token-specific columns. AWS launched FOCUS 1.0 general availability support at re:Invent 2024.

FOCUS 1.2 (Ratified May 29, 2025)

FOCUS 1.2 introduced 65 standardized columns (up from ~40) grouped into six categories. Key changes relevant to AI/ML:

SaaS and PaaS unification: The central change. FOCUS 1.2 folds SaaS and PaaS billing data into the same schema as core cloud spend, which is the pathway for AI API providers (OpenAI via Azure marketplace, Anthropic via AWS Bedrock, Google Gemini via Vertex AI) to emit FOCUS-compliant records alongside IaaS charges.

Non-monetary unit support: Effective cost tracking was extended to non-monetary units, explicitly calling out “credits or tokens” as valid pricing units. This enables token-denominated rows to carry a PricingUnit of tokens and a ConsumedQuantity reflecting actual token consumption — the schema contract that makes cost-per-token analysis possible in FOCUS-native tooling.

New columns added in 1.2:

  • BillingAccountType — distinguishes account types across provider hierarchies (Conditional)
  • PricingCurrency — supports multi-currency scenarios in global enterprise billing
  • Refined EffectiveCost definition covering non-monetary units

AI/ML column gap acknowledged: The specification documentation explicitly notes that “AI tools and services” are “under review” for documentation and will be released once available. FOCUS 1.2 provides the schema extension points but does not mandate AI-specific column definitions.

FOCUS 1.3 (Ratified December 4, 2025)

Three enhancements, none AI-specific but all operationally relevant to AI governance:

Shared Cost Allocation columns: Providers can now expose how they split costs across workloads, benefiting multi-tenant inference endpoints (e.g., a shared Bedrock endpoint serving three product teams).

Contract Commitments Dataset: A dedicated dataset isolating contract terms — start/end dates, remaining units, descriptions. Directly applicable to Provisioned Throughput Units (PTUs) on Azure OpenAI and reserved inference capacity on AWS Bedrock.

Data Quality Metadata: Providers must timestamp datasets and flag completeness status. Addresses a specific AI billing problem: GPU and token usage data frequently arrives with a 24–48 hour delay, causing practitioners to make decisions on incomplete data.

Vendors supporting FOCUS 1.2 as of December 2025: Alibaba, AWS, Databricks, Google Cloud, Grafana, Huawei, Microsoft, Oracle Cloud Infrastructure, OVH Cloud, Tencent.

Future: FOCUS for AI (Post-1.3 Roadmap)

The Foundation has explicitly stated that “future FOCUS versions will expand to additional spending scopes, including data center and AI.” The expected additions include: model identifier columns, token type classification (input/output/cached/reasoning), inference endpoint identifiers, and batch vs. real-time inference flags. No ratification date is published as of June 2026.

3. FinOps for AI Maturity Model

The Foundation’s official framework uses the standard FinOps Crawl / Walk / Run progression, applied specifically to AI cost management capability. The criteria for each stage are defined across three dimensions: cost visibility, cost control, and value attribution.

Crawl — Prototyping Phase

Organizational state: AI is in proof-of-concept or pilot; teams experiment with no hard budget controls.

Cost visibility: Engineers may have access to cloud billing consoles but there is no centralized AI spend view. Token consumption is not tracked separately from general API spend.

Cost control: Informal or no cost limits. Spend alerts may exist at the cloud account level but not at the model, team, or feature level.

Value attribution: No connection between AI spend and business outcomes. Cost treated as R&D overhead.

Success criteria to exit Crawl: Establish a tagged AI spend line item. Assign an owner to AI cost review. Define at least one unit economics metric (e.g., cost-per-API-call).

Walk — Integration Phase

Organizational state: AI features are in production or broad internal deployment. Engineering and finance have established shared visibility.

Cost visibility: Centralized AI cost dashboard. Token consumption tracked by model, API endpoint, and team. Anomaly detection alerts active.

Cost control: Team-level budgets with automatic alerts. Basic showback or chargeback to business units. Commitment discount evaluation (reserved capacity, PTUs) underway.

Value attribution: At least one unit economics metric tracked consistently. AI ROI framed at the feature or product level, not just total cost.

Success criteria to exit Walk: Achieve 90%+ forecast accuracy for AI spend with documented cost drivers. Unit economics metrics reviewed in regular business reviews. Optimization decisions (quantization, model routing, caching) factored into financial planning.

Run — Core Business Process Phase

Organizational state: AI is a core business process. AI cost governance integrated into product planning, sprint cycles, and P&L management.

Cost visibility: Real-time cost attribution to business outcomes. Shadow AI discovered and managed. Full FOCUS-compliant data ingestion across cloud and SaaS AI spend.

Cost control: Automated optimization triggers (e.g., auto-routing to smaller models below quality threshold). FinOps and engineering jointly own cost-performance Pareto curves. AI spend included in zero-based budget reviews.

Value attribution: Revenue or margin per AI feature tracked alongside cost. Model efficiency ratios reviewed quarterly. AI cost included in product pricing decisions.

Maturity gap (State of FinOps 2026): Only 14.2% of surveyed organizations are at Run maturity across FinOps broadly. The gap is wider for AI specifically — the Foundation estimates fewer than 10% of organizations currently apply Run-level practices to AI cost governance.

4. Unit Economics for AI: Foundation Definitions and Formulas

The Foundation defines AI unit economics as “decomposing both costs and output characteristics to establish the cost of a discrete, repeatable unit of AI value delivered.”

Primary Unit Economics Metrics

Cost Per Inference

Cost Per Inference = Total Inference Cost (period) / Total Inference Request Count (period)

Tracks all costs attributed to serving a single AI request: token charges, compute overhead, embedding retrieval, and orchestration. The Foundation recommends separating batch inference from real-time inference, as their economics diverge significantly.

Cost Per Token (Input and Output Separately)

Cost Per Input Token = Total Input Token Charges / Total Input Tokens Consumed
Cost Per Output Token = Total Output Token Charges / Total Output Tokens Consumed

Both must be tracked independently. Output tokens typically cost 3–5x input tokens on major providers. Reasoning model outputs are a further distinct tier — internal reasoning tokens are often billed at output rates but deliver no direct user value, making the effective cost-per-useful-output-token substantially higher.

Cost Per Outcome

Cost Per Outcome = Total AI Spend Attributed to Use Case / Successful Outcomes Delivered

“Outcome” is defined per use case: a resolved support ticket, a generated code review, a completed document summarization. The Foundation recommends defining outcomes before deploying AI features to enable retroactive costing.

Token Yield Rate

Token Yield Rate = Tokens Contributing to Downstream Business Action / Total Tokens Generated

Accounts for abandoned sessions, retried requests, and low-quality outputs that do not produce business value. A low yield rate (e.g., 40%) indicates that effective per-outcome cost is 2.5x the apparent per-token cost. The Foundation identifies this as a primary hidden cost driver in agentic workloads where multi-step tool use generates large token volumes for failed paths.

Model Efficiency Ratio

Model Efficiency Ratio = Business Value Score (normalized) / Cost Per Inference

Compares models at equivalent quality points. Used to justify routing cheaper models for lower-complexity tasks. Requires a defined quality scoring mechanism (e.g., RAGAS for RAG quality, human evaluation samples).

Training Cost Efficiency

Training Cost Efficiency = Improvement in Model Performance Score / Total Training Spend

Applied to fine-tuning decisions. Benchmarks the marginal performance gain per dollar of fine-tuning vs. prompt engineering alternatives.

The Five Cost Drivers Per Request (Foundation Framework)

The Foundation’s token economics paper identifies five compounding cost factors that make AI costs non-linear relative to user activity:

  1. System prompt overhead — standing instructions added to every call; grows with governance requirements
  2. Context and memory — retrieved documents, conversation history, tool definitions injected at runtime
  3. Model selection — reasoning-class models generate internal tokens not visible to users
  4. Output length — driven by prompt design and model behavior, not just user intent
  5. Retry and orchestration overhead — failed tool calls, validation loops, agent-to-agent communication in multi-agent architectures

Complete AI Cost Stack

The Foundation explicitly flags that token pricing captures only the marginal inference cost. The full TCO stack:

Layer Cost Type Notes
Foundation model inference Variable (token-metered) Primary visible cost
Cloud compute / GPU hours Variable + Reserved SageMaker, Vertex AI, Bedrock compute
Vector database / storage Semi-fixed Grows with knowledge base size
Networking and egress Variable Often overlooked at scale
SaaS AI tools Fixed + Variable Metering often obscured in subscriptions
MLOps and observability Fixed (headcount + tooling) Evals, tracing, prompt management
Data acquisition / licensing Fixed Training data, benchmark licenses
Shadow AI Unmeasured variable Unsanctioned tool use across the org
Fine-tuning / retraining Periodic capital GPU reservations or spot spend

5. FinOps for AI Spend Taxonomy

The Foundation categorizes AI spend across five primary spend types, each with distinct billing models, optimization levers, and governance requirements.

Training

Definition: Compute spend to train or fine-tune a model from a base checkpoint, including data preprocessing, distributed training runs, and validation passes.

Typical share of lifecycle cost: 5–15% for task-specific fine-tuning; higher (30–50%) for organizations pre-training domain-specific models.

Billing model: GPU/TPU instance-hours (spot or reserved). Per-unit compute charge with no usage-based variability once the job starts.

Optimization levers: Spot instance usage, quantization (4-bit, 8-bit) reducing memory and compute requirements by 4–16x, parameter-efficient fine-tuning (LoRA, QLoRA) reducing trainable parameters and compute time.

Governance requirement: Training jobs need pre-approval thresholds because a single misconfigured job can consume a month’s budget in hours.

Inference

Definition: The cost of serving model outputs to users or downstream systems in real time (online inference) or in bulk (batch inference).

Billing models:

  • Per-token (e.g., OpenAI API, Anthropic API, AWS Bedrock on-demand): variable, scales directly with usage
  • Provisioned Throughput Units / PTUs (e.g., Azure OpenAI PTU, AWS Bedrock Provisioned): reserved capacity with a fixed hourly charge regardless of utilization
  • Instance-hour (e.g., self-hosted vLLM on EC2): fixed compute cost independent of token volume

Key distinction: Per-token vs. per-instance billing produces “vastly different economics” depending on utilization. At >60–70% GPU utilization, provisioned/instance pricing outperforms per-token. Below that threshold, on-demand per-token is cheaper.

Optimization levers: Model routing (route simpler queries to cheaper models), prompt caching (cache repeated system prompts), output length control, batching requests to improve GPU utilization.

Fine-Tuning

Definition: Adapting a pre-trained foundation model to a specific domain or task using organization-specific data. Distinct from full training in scale and cost.

Billing model: Typically per-token for the fine-tuning dataset (training token charges) plus compute hours for the fine-tuning job.

Cost consideration: Fine-tuning costs must be amortized across all inferences the fine-tuned model will serve. A $10,000 fine-tuning run amortized over 10M inferences adds $0.001 per inference — often cheaper than prompt engineering that adds 500 tokens per call.

Embeddings

Definition: Converting text, images, or documents into high-dimensional vector representations for storage and retrieval in vector databases.

Billing model: Per-token for embedding generation. Much cheaper than inference (typically 10–100x cheaper per token) but can reach significant scale when re-embedding large knowledge bases.

Storage component: Vector database costs (Pinecone, Weaviate, pgvector) are ongoing fixed or usage-based charges that scale with the number of vectors stored. The Foundation notes that “at scale, storage costs can rival compute as a cost driver.”

Optimization levers: Chunking strategy (larger chunks = fewer embeddings), re-embedding frequency policies, vector compression (quantized embeddings).

Storage and Data Management

Definition: All persistent storage costs across the AI lifecycle — training datasets, model checkpoints, embedding stores, inference logs, evaluation datasets, and model artifacts.

Cost growth pattern: Storage costs compound over time as organizations accumulate training iterations, experiment artifacts, and audit logs. The Foundation identifies storage as a “significant and growing portion of AI TCO that is easy to overlook.”

Governance requirement: Retention policies and lifecycle rules applied to model artifacts and training data. Many organizations store all model checkpoints indefinitely, creating avoidable storage costs.

6. Cloud Provider FOCUS Compliance: AI/ML Billing Status

AWS

FOCUS version support: FOCUS 1.0 reached general availability at re:Invent 2024. FOCUS 1.2 support announced as “actively in development” at FinOps X 2025, with GA expected in 2025. Data exported via AWS Data Exports for FOCUS in the Billing and Cost Management console.

AI/ML services in FOCUS export: Amazon Bedrock, SageMaker, and Bedrock inference charges appear in FOCUS exports with ServiceName and ResourceId columns identifying the model endpoint. Token consumption maps to ConsumedQuantity with PricingUnit of tokens. Bedrock model unit costs visualized in CUDOS Dashboard 5.6.

Gaps: Model identifier (which foundation model was invoked) is not a dedicated FOCUS column — it must be parsed from ResourceId or retrieved via CloudTrail. Batch inference and real-time inference are not distinguished by a dedicated FOCUS flag.

Microsoft Azure

FOCUS version support: Azure Cost Management exports FOCUS 1.0-aligned data. Azure is a FOCUS 1.2 listed supporter. Azure FinOps Hub provides FOCUS-native cost reporting including multi-cloud (Azure + Google Cloud).

AI/ML services in FOCUS export: Azure OpenAI Service charges appear in FOCUS exports. The Azure FinOps Toolkit (open source, Microsoft-maintained) specifically documents mapping Azure OpenAI token charges to FOCUS columns: ConsumedQuantity = tokens used, PricingQuantity = tokens billed (may differ due to minimum billing increments), PricingUnit = tokens. PTU reservations appear under CommitmentDiscount columns.

Notable: Azure is the furthest ahead on AI-specific FOCUS documentation, with a dedicated Microsoft Community Hub blog post (“Managing Azure OpenAI costs with the FinOps toolkit and FOCUS: Turning tokens into unit economics”) detailing the exact column mapping.

Google Cloud

FOCUS version support: Google Cloud announced a “first-class Billing BigQuery Export supporting FOCUS 1.0” in limited private preview at FinOps X 2025. Listed as a FOCUS 1.2 supporter. Data flows through BigQuery, enabling SQL-based analysis alongside other cloud cost data.

AI/ML services in FOCUS export: Vertex AI and Gemini API charges are included in BigQuery billing exports. Token charges map to standard usage columns. Gemini Cloud Assist identifies resource waste and generates cost optimization recommendations natively within Google Cloud Console.

Gaps: Private preview status for FOCUS export means general availability timeline is not confirmed. Full FOCUS 1.2 feature parity not yet documented.

Oracle Cloud Infrastructure (OCI)

FOCUS version support: OCI is a FOCUS 1.2 listed supporter. Cost anomaly detection and carbon emissions reporting announced at FinOps X 2025. Positioned as a fast follower to the three hyperscalers on FOCUS compliance.

Databricks

FOCUS version support: Databricks listed as FOCUS 1.2 supporter (December 2025 announcement). Relevant for organizations running AI training workloads and LLM fine-tuning on Databricks clusters, where Databricks Unit (DBU) charges can now be normalized to FOCUS schema alongside cloud provider costs.

7. State of FinOps 2026: Practitioner Survey Findings on AI Spend

Source: FinOps Foundation State of FinOps Survey 2026 (n=~2,000+ practitioners, published early 2026).

Adoption

  • 98% of organizations now actively manage AI costs — up from 63% in 2025 and 31% in 2024. AI cost management has moved from an emerging concern to a universal FinOps scope item in two years.
  • 58% of teams list AI cost management as the #1 skillset they are seeking to add.
  • Many organizations report being asked to self-fund AI investments through FinOps efficiency gains, creating a direct link between cloud optimization savings and AI budget availability.

Pain Points (Ranked by Practitioner Frequency)

  1. Visibility into AI costs — cited as the top challenge. Practitioners struggle to see token consumption, model usage, and GPU utilization in a single view. Commercial tooling has “not yet delivered this at scale.”
  2. Allocating AI costs to business units — AI services are frequently shared across teams and products; tagging and attribution models built for EC2 instances do not map cleanly to shared inference endpoints.
  3. Determining AI ROI — the hardest problem. One practitioner quoted: “Is your AI providing value? No one can answer that question yet.” Outcome definition precedes ROI measurement, and most teams have not defined outcomes.
  4. Pricing model variability — pricing models vary widely across providers and services (per-token, per-PTU, per-seat, per-API-call). No standardized unit of comparison exists for cross-provider AI spend.
  5. Forecasting accuracy — AI workloads are non-deterministic in consumption; user behavior changes (e.g., enabling an agentic feature) can multiply token consumption without warning.

Maturity Gap

  • 89% of organizations that self-assess as “very mature or leading edge” on FinOps reported AI-related cost overruns in the past 12 months — indicating that traditional FinOps maturity does not transfer to AI cost management.
  • Fewer than 20% of practitioners are currently applying unit economics to AI spend.
  • Only 14.2% of respondents are at “Run” maturity in FinOps overall; AI maturity lags further behind.

Top Tooling Request

Granular monitoring of AI spend — specifically: token consumption by model/team/feature, LLM request counts, and GPU utilization — ranked as the #1 desired capability that commercial platforms have not yet delivered at scale.

AI for FinOps (Reverse Direction)

The survey also captures FinOps teams’ use of AI within their own practice:

  • Anomaly detection and faster alerting (highest adoption)
  • Automated right-sizing recommendations
  • Natural language querying of cost data
  • Automated discount procurement and commitment management

The FinOps for AI Overview document defines a ten-KPI library. The Foundation recommends instrumenting all ten for Run-maturity organizations, and a minimum of five for Walk-maturity organizations.

Ten Primary KPIs

KPI Formula Frequency Owner
Cost Per Inference Total inference cost / request count Daily Engineering + FinOps
Cost Per Token (input) Input token charges / input tokens Daily Engineering
Cost Per Token (output) Output token charges / output tokens Daily Engineering
Token Yield Rate Value-generating tokens / total tokens Weekly Product + Engineering
Training Cost Efficiency Performance gain / training spend Per run Data Science
Resource Utilization Efficiency Actual GPU utilization / provisioned capacity Hourly Infrastructure
Anomaly Detection Rate Anomalous spend events detected / total events Continuous FinOps
Cost Per API Call Total API cost / API call count Daily Platform
Time to Achieve Business Value Days from model deployment to measurable outcome Per initiative Product
Model Quality Score Alignment Business outcome quality / model benchmark score Per evaluation cycle Data Science

Three KPIs for Executive Reporting

The Foundation recommends surfacing three KPIs to C-suite and board-level AI governance:

1. Cost Per Outcome — connects AI spend to business results in non-technical terms. Requires outcome definition (resolved ticket, generated draft, completed analysis). Reported monthly.

2. AI Spend as Percentage of Revenue Served — normalizes AI cost against the revenue the AI feature or product generates. Enables comparison across AI initiatives of different scales. Reported quarterly.

3. Model Efficiency Ratio — quality-adjusted cost comparison across model tiers. Justifies optimization investments and model substitution decisions. Reported quarterly.

9. FinOps for AI vs. Traditional FinOps: Key Differences

Billing Unit

Traditional FinOps: CPU-hours, GB-months, API call counts — discrete, countable, and deterministic given fixed workloads.

AI FinOps: Tokens — a sub-word unit with no fixed relationship to user requests. A single user question can generate 50 or 50,000 tokens depending on model behavior, retrieval results, and reasoning depth. Token counts are non-deterministic for a given input.

Cost Predictability

Traditional FinOps: Rightsizing, scheduling, and reserved instances reduce uncertainty to predictable ranges. Infrastructure costs respond linearly to scale.

AI FinOps: Token consumption has non-linear elasticity. Enabling an agentic feature, extending context windows, or adding a reasoning step can multiply costs by an order of magnitude without changing the user-facing interaction. The Foundation notes that “even when cost per token declines, organizations expand modality (text to image to video), increase agent autonomy, and lengthen reasoning chains,” making net AI spend growth difficult to control through unit price optimization alone.

Price Dynamics

Traditional FinOps: Cloud compute prices decline gradually (10–20% annually), with reservation discounts of 30–60% providing budget stability.

AI FinOps: Token prices dropped 90%+ on some models between 2023 and 2025, then stabilized as providers shifted to subscription-plus-consumption pricing. Frontier reasoning models (o3, Claude Opus 4, Gemini Ultra) are not following the commodity price curve — their per-token prices are rising relative to 2024 baselines as consumption grows. The 2026 environment is characterized by the end of the subsidy phase: providers have moved to “seat-fee-plus-pre-committed-token-consumption structures with no included usage cushion.”

Optimization Paradox

Traditional FinOps: Rightsizing reduces cost without changing workload output.

AI FinOps: Many optimization techniques (quantization, model routing, context compression) reduce cost but may affect output quality. Every optimization is a quality/cost tradeoff requiring Product and Data Science sign-off — not a unilateral FinOps decision. The Foundation codifies this as requiring “Product and Engineering to jointly own cost-performance Pareto curves.”

Governance Timing

Traditional FinOps: Cost review happens post-billing (weekly or monthly cycle).

AI FinOps: Cost governance must happen at runtime. The Foundation’s 2026 framing: “the structural requirement is integrating economic accountability into the AI workflow itself, at runtime, not in a post-billing review.” Guardrails (token budgets, spend caps per session) must be implemented in code, not in spreadsheets.

Shadow Spend

Traditional FinOps: Shadow IT typically means unsanctioned cloud accounts. Discoverable via billing aggregation.

AI FinOps: Shadow AI includes consumer SaaS tools with AI features (Notion AI, Copilot for M365, Cursor), developer AI subscriptions expensed through T&E, and AI capabilities embedded in existing SaaS contracts without exposure of consumption data. The Foundation identifies SaaS-embedded AI as a “structurally invisible” cost category — it does not appear in cloud bills and requires ITAM/SAM integration to surface.

10. Integration Patterns: FOCUS AI Data into FinOps Tooling

IBM Cloudability (formerly Apptio)

IBM completed its acquisition of Apptio in August 2023. The product is now marketed as “IBM Cloudability.” FOCUS 1.0-aligned data ingestion is supported. Cloudability ingests cloud provider FOCUS exports and maps them to its TBM (Technology Business Management) taxonomy, enabling allocation from resource-level AI costs to IT Tower and Business Capability layers.

AI-specific integration pattern: AI spend tagged with model endpoint, team, and use case flows from AWS/Azure/GCP FOCUS exports into Cloudability’s allocation engine. Token charges are treated as metered services in the TBM hierarchy. The limitation: Cloudability’s TBM model was designed for infrastructure towers, not for AI unit economics — practitioners report manually building unit economics dashboards outside the platform.

Flexera One

Flexera completed its acquisition of Spot by NetApp in March 2025, adding GPU reservation optimization and AI workload scheduling to its portfolio. Flexera adopted FOCUS 1.0 specification for cost data normalization. Named a Leader in the Gartner Magic Quadrant for Cloud Financial Management Tools (2024, 2025).

AI-specific integration pattern: Flexera ingests FOCUS-formatted exports and normalizes them alongside ITAM (software license) data. This addresses the hybrid nature of AI spend — a single AI initiative may incur GPU charges (cloud bill, FOCUS-covered), OpenAI API charges (cloud marketplace, partial FOCUS coverage), and Copilot for M365 seat licenses (SaaS, ITAM domain). Flexera’s combined ITAM + FinOps view is the most complete currently available for total AI spend visibility.

CloudHealth by Broadcom

Broadcom acquired VMware (which owned CloudHealth) in 2023. In June 2025, Broadcom announced a new CloudHealth UX with “Intelligent Assist” and “Smart Summary” AI-powered features. CloudHealth supports FOCUS data ingestion for multi-cloud normalization.

AI-specific integration pattern: CloudHealth’s policy engine can be configured with AI-specific rules (e.g., alert when a team’s token spend exceeds $X/day; flag inference endpoints with <30% utilization against provisioned capacity). The FOCUS data provides the normalized input; CloudHealth’s rule engine provides the governance layer. Practitioners use CloudHealth’s ShowBack reports to attribute AI spend to business units using tag hierarchies.

Common Integration Architecture

The Foundation’s recommended data flow for AI cost management in FOCUS-native tooling:

Cloud Provider Billing APIs
        │
        ▼
FOCUS Export (S3 / BigQuery / Azure Storage)
        │
        ▼
FOCUS Ingest Layer (ETL to normalize all providers)
        │
        ▼
Enrichment Layer
  ├── Tag enrichment (CMDB → cost center, application, team)
  ├── AI metadata join (model registry → model name, version, tier)
  └── Business outcome join (product analytics → outcome events)
        │
        ▼
FinOps Platform (Cloudability / Flexera / CloudHealth / custom)
        │
   ┌────┴────┐
   ▼         ▼
Showback   Unit Economics
Dashboard  Reports

The “AI metadata join” step is currently manual at most organizations — model endpoint IDs must be mapped to human-readable model names and cost tiers via a registry that does not yet exist in FOCUS schema.

11. FinOps Foundation Training and Certification for AI

FinOps Certified: FinOps for AI (Launched June 2025)

The Foundation launched a dedicated four-part AI certification series in June 2025, separate from the existing FinOps Certified Practitioner (FOCP) credential.

Structure:

  • Introduction to FinOps for AI — Available June 2025. Foundational concepts: AI billing models, token economics, the Crawl/Walk/Run maturity model for AI.
  • FinOps for AI Trained: Level 1 — Available September 2025. AI cost allocation, showback/chargeback for AI workloads, GPU reservation management.
  • FinOps for AI Trained: Level 2 — Available November 2025. Unit economics implementation, forecasting AI spend, optimization techniques and their financial modeling.
  • FinOps for AI Trained: Level 3 — Available January 2026. Advanced governance, ROI measurement frameworks, sustainability/GreenOps for AI, regulatory compliance considerations.
  • FinOps Certified: FinOps for AI Exam — Available March 2026. Cumulative exam across all three levels. Earns the “Certified FinOps for AI” credential.

Curriculum emphasis: AI-specific cost allocation, chargeback models for token-metered services, workload optimization with quality/cost tradeoff frameworks, unit economics and sustainability, AI investment governance and ROI alignment.

Approach: Described as “agile and iterative” — content released in phases rather than as a finished curriculum, incorporating practitioner feedback from early cohorts.

Existing FOCP Curriculum Updates

The FinOps Certified Practitioner (FOCP) exam — the Foundation’s primary certification — was updated in 2025 to include AI cost management as a domain. FOCP remains the prerequisite recommended before pursuing the AI-specific certification.

12. FinOps for AI vs. ITFM: Where They Diverge

Foundational Difference

ITFM (IT Financial Management) is a top-down discipline driven by the CIO and CFO, operating on monthly/quarterly budget cycles, producing plan-vs-actual variance analysis, and allocating technology cost to business units through a TBM taxonomy. It prioritizes accuracy, auditability, and alignment to General Ledger.

FinOps is a bottom-up operational discipline driven by engineering and FinOps practitioners, operating in near-real-time on billing API data, producing consumption-level optimization recommendations, and attributing cost through tags and resource hierarchies. It prioritizes speed, granularity, and actionability.

Over 80% of companies currently run ITFM and FinOps as independent practices with minimal data sharing.

Where They Diverge on AI

Speed mismatch becomes acute: AI spend can spike orders of magnitude within a single billing period. By the time ITFM sees the overage in a monthly variance report, the engineering behavior that caused it has continued for 3–4 weeks. FinOps alerting must catch this in hours.

Classification gap: ITFM’s TBM taxonomy was designed for infrastructure towers (Compute, Storage, Network, Applications). AI spend cuts across towers: a single AI feature incurs Compute (GPU inference), Storage (vector DB), Application (foundation model API), and potentially a new “AI Capabilities” tower not yet standardized in TBM.

Token costs in SaaS contracts: ITFM teams process AI spend embedded in SaaS renewals (M365 Copilot, Salesforce Einstein, ServiceNow AI) as flat license fees. Token-level consumption data is not exposed by these vendors in formats ITFM systems can process. FinOps + ITAM integration is required to surface the underlying variable component.

Build vs. buy economics: ITFM evaluates build vs. buy at contract renewal. AI introduces a continuous build-vs-buy optimization — organizations may shift workloads between managed API services and self-hosted models multiple times per year as the price-performance frontier moves. ITFM amortization schedules for GPU CapEx or committed capacity reservations do not accommodate this volatility.

Five Integration Points (FinOps Foundation Working Paper)

The Foundation’s FinOps/ITFM intersection working paper defines five collaboration points:

  1. Savings Recognition: FinOps quantifies optimization savings (e.g., model routing saved $120K/month); ITFM validates and formally removes from the approved budget line.
  2. Chargeback Design: FinOps provides token-level attribution logic; ITFM executes the General Ledger posting and cost center allocation.
  3. Budget Forecasting: FinOps consumption trend data feeds ITFM’s financial forecast before period close — critical because AI budgets set in Q4 are frequently obsolete by Q2 given price changes.
  4. Variance Analysis: Joint decomposition of price variance (token price change) vs. volume variance (consumption change) using a shared analytical model.
  5. Tagging Standards: Six shared tag identifiers enforced at deployment: cost center, application, entity, environment, project, owner.

Best Practice Recommendation

The Foundation recommends that organizations “establish AI as a distinguishable, attributable cost dimension at the point of contract” — requiring separate line items for token consumption versus license fees flowing through accounts payable before AI consumption scales. This creates the audit trail ITFM requires while enabling the granularity FinOps needs.

Sources and Primary References