What Stater Is (and What It Isn't)

What Stater is

Stater is the operating discipline for AI value. It is a sub-discipline of FinOps for AI: tokens are its unit of accounting, the way compute-hours were the unit of cloud FinOps. But token accounting is where the discipline starts, not where it ends. Tokens are the centre of gravity, not the perimeter. A Stater function that only counted tokens would miss most of what determines whether an AI initiative makes money — model selection, architecture, agentic guardrails, and the cost of being wrong all sit inside the discipline even though none of them is a line item on a token invoice.

The reason a new discipline is needed is that AI economics are not cloud economics. A virtual machine costs a fixed amount per hour whether it is working or idle; its cost is decoupled from outcomes and tied to time. A token-billed system is the opposite. Cost is decoupled from time and tied directly to the shape of the work: how long the prompt is, how much the model reasons, whether the response is a single-word classification or a thousand-word essay, whether a cache was hit, whether an agent looped. The same task can cost wildly different amounts on two different runs. Finance teams that treat token spend as just another cloud line item are, in the words used at the April 2026 FinOps Foundation Summit, missing the point — "the new job of the FinOps team is to maximise the value of the tokens," not merely to track their cost.

What a Stater function actually does

Stater resolves into three jobs. The first is to measure: to attribute spend to teams, features, and customers, and to express it as unit economics rather than a monthly total. This is mostly an instrumentation problem — routing traffic through a gateway, enforcing metadata tags at the call site — and it is the day-one unlock, because you cannot govern or optimise what you cannot see.

The second is to govern: to put guardrails around probabilistic spend. Circuit breakers and dollar caps stop a runaway agent loop from producing a five-figure overnight bill. Model-tiering policies stop every task defaulting to the most expensive frontier model. Showback and chargeback designs decide who carries the cost and therefore who has the incentive to reduce it.

The third is to optimise: to make the same outcomes cost less over time. Routing low-complexity work to cheaper models, structuring prompts so static context is cached, capping agent loops before they thrash — each of these is a lever, and the discipline is knowing which one a given workload needs.

What Stater is not

Stater is not a parallel framework competing with FinOps. The FinOps Foundation has its own "FinOps for AI" and "AI value" vocabulary, and Stater is a named sub-discipline inside it, not a rival to it. The intent is to give a fast-growing role a canonical playbook, not to fork the field.

Stater is not cost-cutting. A discipline whose only goal was a smaller bill would tell you to use AI less. The goal is the opposite: to give a business the visibility and the guardrails it needs to scale AI without flying blind. Saving money is a side effect of doing the accounting properly; the actual product is permission to grow.

Stater is not purely an engineering concern, and it is not purely a finance concern. Its defining feature is that it sits on the seam between the two. Engineering optimises latency and quality; finance optimises margin; the failure mode that creates the need for Stater is that, left to themselves, neither owns the translation between token mechanics and the P&L. That translation is the job — and the person who owns it is the AI FinOps Lead, the role this guide specifies in detail in Section 11.