FinOps, TVR and AI cost questions, answered directly.

Technology Value Realization (TVR) is the discipline of connecting every technology cost (AI, cloud, data, Kubernetes, on-premise and SaaS) to the business value it produces. It is operationalized through four stages: See, Attribute, Optimize, Realize. TVR extends FinOps across every cost domain and forward from cost visibility to value proof.

Read the full framework →

FinOps established cloud cost accountability and remains the foundation; TVR extends it in two directions. Across every technology cost domain rather than public cloud alone, and forward from cost visibility to value proof, where the deliverable is a unit metric tied to a business outcome rather than a spend report. A mature FinOps practice is a prerequisite for TVR, not an alternative to it.

TBM operates at the IT financial planning layer; TVR operates at the operational cost-to-value layer. TBM handles budgets, portfolio cost, application cost models and business-unit showback. TVR handles live cost attribution and unit economics across cloud, AI, data and Kubernetes, and feeds those numbers upward into TBM planning models. Large enterprises commonly run both.

See the three-layer model →

Every cost record is written directly into the FinOps Open Cost and Usage Specification schema at the moment of ingestion, with no proprietary intermediate model. This delivers roughly 30% lower data-processing cost, no translation delay, and a vendor-portable dataset. Exporting to FOCUS on request is a different and considerably weaker property.

Invoice truth is what the vendor billed: authoritative, late, coarse. Execution truth is what actually ran: immediate, granular, unpriced. A platform holding only invoices cannot say which pipeline run caused a spike; one holding only telemetry cannot say what it cost. Joining both in one schema is a precondition for accurate attribution.

A composite unit metric spans multiple cost domains in one formula: for example AI-inclusive cost per customer, combining cloud compute, model tokens, warehouse credits, Kubernetes pods and SaaS seats. It is only computable when every domain shares one schema. Point tools each produce a fraction of the answer, and adding those fractions by hand is not the same number.

It is the FinOps Foundation's staged progression, and it maps cleanly onto TVR. Crawl: one domain visible in FOCUS, ownership at business-unit level, one published unit metric. Walk: three or more domains, auditable sequenced chargeback with quality grading, savings verified rather than estimated. Run: every domain including on-premise and SaaS, attribution trusted enough to drive budgets, composite metrics in the board pack.

Start where the gap between spend and understanding is widest: for most enterprises in 2026 that is AI. Spend is growing fastest, attribution is weakest, and executive scrutiny is highest. Instrument one stage at a time, and do not move to attribution until visibility is complete for that domain, because attribution built on partial data produces confident nonsense.

Cost per merged pull request is the total AI agent spend attributable to a set of pull requests, divided by the number of those pull requests that were merged. It measures whether engineering AI spend is compounding into shipped software rather than into abandoned branches, and it is the signature value metric for the AI domain in TVR.

Through commit attestation, not estimation. Coding agents emit run telemetry via OpenTelemetry containing run identifiers, token counts and durations. Commits produced during those runs carry an attestation referencing the run identifier. The platform joins the priced run to the merged pull request through that reference, so cost lands on delivered work rather than an undifferentiated team total.

Traced coverage is the proportion of total AI spend that could be attributed to specific delivered output. It matters because a cost-per-output metric computed over 40% coverage means something very different from one computed over 90%. Reporting allocated plus untraced spend as equaling the invoice total keeps the denominator explicit instead of hidden.

Agentic workloads consume roughly 5–30× the tokens of a single chatbot interaction per task, because they plan, call tools and iterate autonomously. This is why AI cost lines grow by multiples rather than percentages once agents reach production, and why token spend needs a governance discipline of its own rather than a line on a cloud report.

Tokenomics is the FinOps discipline concerned with the cost behavior of AI token consumption: caching, batching, model selection, context management and prompt efficiency. The FinOps Foundation formalized it as a distinct practice area in 2026, recognizing that AI spend behaves differently enough from infrastructure spend to need separate treatment.

Provisioned Throughput Units are reserved AI model capacity purchased for guaranteed throughput rather than billed per token. PTUs are economical above a utilization threshold and expensive below it, which makes matching provisioned capacity to actual utilization one of the highest-value AI optimization scenarios, and one of the easiest to get wrong at purchase.

Major model providers offer approximately a 50% discount for batch processing where latency is not critical. Workloads that are batch-eligible but submitted synchronously leave that discount unclaimed. It is a common and largely invisible source of AI waste, because the absolute spend is still rising for legitimate adoption reasons.

It means the platform exposes its full data model through the Model Context Protocol, so Claude, Copilot, Gemini or an in-house LLM can query cost and value data conversationally. Access control is inherited: the AI assistant receives exactly the permissions of the person asking, never more. Without that inheritance, conversational access becomes a data-governance problem.

Attribution quality grading labels every allocated cost with how it was attributed: directly tagged, inferred from usage, or distributed by a shared-service rule. A chargeback showing 78% direct and 22% rule-distributed can be defended in a budget review. A single undifferentiated number cannot, and that is where most chargeback programs quietly lose credibility.

Auditable sequenced chargeback runs allocation as an ordered pipeline (invoice, then environment, then project, then team) where each stage records its rule, inputs and outputs. Any final number can be walked backwards to its source, which is what makes the result survive an audit or a disputed budget review rather than merely look complete.

Showback reports cost to a team for visibility; chargeback moves the cost onto their budget. Chargeback demands far higher attribution quality, because a number that affects someone's budget will be disputed and must survive the dispute. Many organizations attempt chargeback on showback-grade data and lose the argument once.

Identified savings are recommended; applied savings are changes made but not yet confirmed in billing; verified-realized savings are reductions confirmed in subsequent invoices. Most tools report the first and let everyone assume the third. The gap between them is precisely where FinOps programs lose executive confidence, so closing it is what turns a cost practice into a value practice.

Unit economics is any cost slice divided by any business metric: cost per customer, per workload, per pipeline run, per active seat. It converts an absolute spend figure into a ratio that can be judged as improving or worsening. "Spend fell 8%" cannot be judged good or bad; "cost per active customer fell 8% while customers grew 20%" can.

In an AI-era cluster, CPU is frequently the cheapest resource on the node. Effective rightsizing covers five dimensions: GPU (MIG partition matching, time-slicing, bin-packing), CPU, memory (requests versus limits, VPA, HPA, KEDA, Karpenter, spot), storage (orphaned persistent volumes, snapshot sprawl) and network (cross-AZ traffic, idle load balancers, NAT gateways).

Idle capacity is provisioned infrastructure that is reserved but unused: cluster headroom, over-requested pods, unattached volumes, idle load balancers. Treating it as its own attributable line rather than overhead distributed silently matters for a simple reason: headroom that nobody owns is headroom that nobody reduces.

NVIDIA Multi-Instance GPU divides one physical GPU into isolated instances. Matching workload requirements to partition size is a primary GPU cost lever: running an inference job on a full A100 when a 1g.10gb slice would serve is among the most expensive routine mistakes in AI infrastructure, and it is invisible without partition-level telemetry.

Applying start/stop schedules to non-production environments typically captures around 70% of non-production compute cost, because development and test resources are commonly idle outside working hours yet billed continuously. It is usually the fastest material cloud saving available, and the least disruptive to production.

By normalizing CAPEX amortization, ISV licenses, facilities and mainframe MIPS into the same schema as cloud spend, then comparing on a unit basis: cost per VM, per host-hour, per workload. Comparing a cloud invoice against a data center budget line is not a comparison at all, because the two include fundamentally different things.

Because an invoice total cannot tell you which job, warehouse or query drove the change. System-table-level ingestion gives DBUs by cluster and job, credits by warehouse and query, and Atlas cost by project, which is what makes cost per pipeline run computable and what catches a pipeline whose run cost doubled after a schema change.

A vendor charging a percentage of your cloud bill earns more when your bill grows, which inverts the incentive you are buying. It also scales punitively with AI adoption, where token spend can grow tenfold in a year while the tool's own workload barely changes. A flat tiered license keeps the vendor's incentive aligned with reducing your cost.

See the three-year arithmetic →

Models vary, and the model matters more than the number. Percentage-of-spend vendors typically charge 1–5% of the cloud bill, so cost rises with your spend. DigiUsher charges a flat annual subscription set by an agreed consumption tier: growth within a tier does not change the fee, and marketplace procurement can draw the license down against an existing EDP or MACC commitment.

A Microsoft Azure Consumption Commitment is a negotiated multi-year spend commitment, and eligible Azure Marketplace software purchases count toward drawing it down. AWS Marketplace purchases similarly draw down an Enterprise Discount Program commitment. Buying software through marketplace therefore consumes budget already committed rather than opening a new budget line.

A Consulting Partner Private Offer is a cloud marketplace mechanism allowing a system integrator to resell a software license to an end customer through the marketplace. The transaction draws down the customer's cloud commitment while the partner bills its own implementation services separately, which is how most GSI-led enterprise deals are structured.

First insight is achievable within 48 hours of connecting a billing source, with full enterprise integration in two to four weeks. Because each TVR stage delivers standalone value, adoption need not wait on a big-bang program. One European enterprise realized €1M in verified savings within 45 days of starting.

Shelfware is purchased licenses or SaaS seats that are provisioned but not actively used. It is surfaced by allocating SaaS cost against real seat activity rather than seat count, which exposes the difference between what procurement bought and what the organization actually uses, usually an uncomfortable number at renewal.

Usually not: Apptio is complementary rather than competitive. Apptio operates at the technology business management layer: IT financial planning, budgeting, portfolio cost. DigiUsher operates at the operational cost-to-value layer across cloud, AI, data and Kubernetes. Many enterprises run both, with DigiUsher supplying attributed cost into Apptio's planning models. Cloudability overlaps more directly on cloud cost reporting.

CloudZero is strong at cloud cost intelligence and unit cost per customer within public cloud; DigiUsher covers a wider estate. AI models and agents, Databricks, Snowflake, MongoDB Atlas, Kubernetes at node, pod, cluster, daemonset, replicaset, deployment and namespace level, on-premise and SaaS, all in one FOCUS-native schema, with flexible deployment available and flat rather than percentage pricing. If your spend is essentially all AWS and percentage pricing is acceptable, CloudZero is a reasonable choice.

Full comparisons →

No. DigiUsher ingests Kubernetes cost at node, pod, cluster, daemonset, replicaset, deployment and namespace level through native mechanisms such as EKS Split Cost Allocation and AKS cost allocation, plus label ingestion for on-premise clusters, and rightsizes across five dimensions. Teams already running OpenCost can use DigiUsher as a single source of truth.

When the estate is one cloud, the data team has capacity, and cost is not yet a board-level topic. In-house pipelines typically struggle after about eighteen months with four things: maintaining FOCUS conformance as vendor formats change, AI agent attribution, an approval-governed change pipeline, and having someone accountable when the numbers are wrong the week before a board meeting.

Four things beyond dashboards. Whether attribution quality is graded rather than asserted; whether AI and agent spend can be tied to delivered output; whether the pricing model still makes sense at three times your current spend; and whether savings are reported as verified-realized rather than merely identified. Every vendor demos well on dashboards.

Three situations, stated plainly. If you need multi-year IT budget planning and application portfolio cost at the ITFM layer, that is Apptio's job. Below roughly $500K annual technology spend, native cloud tooling plus discipline is sufficient. And if you want a tool that resizes production autonomously without human review, our governance model will feel like friction rather than safety.

Bring Your Own Cloud means the entire platform runs inside your own cloud account or data center, so no cost, usage, telemetry or workload data leaves your perimeter. The vendor is therefore a software provider rather than a data processor under UK and EU GDPR, which materially shortens third-party risk assessment under FCA, PRA, MAS TRM, DORA and FedRAMP frameworks.

Architecture and regulatory mapping →

No, and it should not. Cost attribution requires token counts, model identifiers, run identifiers, commit SHAs and diff metadata. It does not require prompt text, model responses, tool payloads or source code bodies. Those should be discarded at the ingestion boundary by architectural rule rather than by configuration, so they cannot be retained even through misconfiguration.

It should not do so silently. In a governed workflow automation, a recommendation becomes a pull request against the repository that owns the resource, carrying its evidence, reviewed by the engineers who own the service, and applied by the same Terraform run as everything else. The pipeline holds no write credentials, and the audit trail is the git history, where auditors already look.

Aggregate-only mode disables all individual-level attribution views organization-wide. It is used to satisfy works-council agreements and employee-monitoring restrictions in EU jurisdictions, where per-engineer cost visibility would otherwise require separate consultation before deployment. Without it, per-developer AI cost reporting can stall a German or Dutch rollout entirely.

The customer should own it at all times, with the vendor holding only a limited license to process it in order to provide the service. Insist on three things: the dataset written to an open specification such as FOCUS, exportable from day one, and a contractual commitment that the vendor does not use customer data to train models or build benchmark products.

See our contractual position →