A few months ago I sat in a budget meeting where someone asked a simple question: what are we actually spending on AI tooling per user per month? Nobody in the room could answer it. Not approximately. Not even within an order of magnitude.
That is the moment I started paying closer attention to how enterprise AI billing is evolving, because the answer to that question is becoming genuinely difficult in a way it was not two years ago.
The old model and why it worked
For most of enterprise software history, the billing model was simple. You paid a per-seat license, annually, negotiated with procurement, predictable in the budget, boring in the best way. If you had 500 engineers and a tool cost $50 per seat per month, you paid $25,000 a month. Done. No surprises.
When AI tooling started entering the enterprise, most vendors defaulted to this model because that is what enterprise procurement knows how to handle. GitHub Copilot launched at a flat per-seat rate. Most AI-augmented SaaS tools bundled AI features into existing seat pricing. It felt familiar.
That model is quietly breaking down.
What is changing and why
The economics of serving language models do not fit the per-seat model well. Usage varies enormously between individuals. An engineer who uses an AI coding assistant lightly and one who runs large context windows all day do not cost the vendor remotely the same amount to serve. At small scale this variance averages out and the flat rate works well enough. At enterprise scale with thousands of seats, it stops averaging out and starts creating problems.
Vendors have been absorbing this mismatch, and some are deciding they can no longer afford to. The result is a gradual shift toward consumption-based billing: you pay per token generated or processed, and your bill reflects what you actually use.
This shift is happening unevenly. Some vendors are making it explicit. Anthropic, OpenAI, and Google have always billed API access by token for direct API users. The change is that the tooling built on top of those APIs is increasingly passing token costs through to enterprise customers rather than bundling them into flat seats. And vendors building native AI products are starting to move toward token or credit consumption models for their enterprise tiers.
The reasons are straightforward. Token-based billing aligns costs with usage, which benefits vendors whose cost structure is consumption-based. It also enables tiered pricing based on model capability: a query handled by a smaller, cheaper model costs less than one routed to a larger, more capable model. That granularity is hard to express in a per-seat structure.
What a token is and why it matters for budgeting
If you have not worked directly with language model APIs, the token concept is easy to underestimate.
A token is roughly equivalent to three or four characters of text, or about three quarters of a word in English. A short query like "summarise this email" is maybe ten tokens. A legal contract fed into a model as context might be fifty thousand tokens. A model generating a long response to that contract might produce another several thousand tokens. Input and output are typically priced separately, with output tokens more expensive.
For light, conversational use cases, token costs are genuinely negligible. For heavy enterprise use cases involving large context windows, document processing, or agentic workflows where models chain multiple calls together, the numbers can grow in ways that are not immediately intuitive.
The specific pattern that catches people off guard is agentic AI workflows. If you are building an automated process where an AI model breaks a task into subtasks, calls tools, reads results, synthesises information, and iterates, each step in that chain is generating and consuming tokens. A workflow that feels like one task might be twenty or thirty API calls with the full conversation context passed each time. The token count can be orders of magnitude higher than a simple query-response pattern.
The repercussions for finance and operations teams
In financial services, where I spend most of my time, a few specific consequences are worth thinking through carefully.
Budgeting becomes genuinely hard. Per-seat costs were forecastable. Token consumption depends on how employees use the tools, what use cases get adopted, how deeply AI gets embedded into workflows. Finance teams are used to modelling software costs as headcount times a rate. Token costs require modelling usage patterns that are often not well understood at the point of budget submission.
I have seen two failure modes here. The first is underestimation: a team gets token access approved at a low forecast and then a single high-usage team or a poorly bounded agentic workflow blows the budget in a quarter. The second is overestimation: risk-averse teams provision a token budget ten times what they actually use, the vendor sees low utilisation and questions the renewal, and everyone ends up in an uncomfortable conversation about value.
Cost attribution gets complicated. With per-seat billing, you know who is using what because you know whose seat is active. With token consumption, especially through shared integrations and automated workflows, tracing cost back to business units or projects requires deliberate instrumentation. If you are running a shared AI service layer that multiple teams call into, the billing comes in as a lump sum unless you have built cost attribution into your architecture.
Compliance and audit trails intersect with billing data. Regulated firms often need to demonstrate that AI-assisted decisions were made appropriately, with appropriate human review. In a token-based billing environment, the same logging infrastructure that supports audit trails can also support cost attribution. Getting these aligned from the start is much easier than retrofitting it.
Vendor negotiations shift. Enterprise software negotiations typically involve volume discounts tied to seat count. Token-based negotiations involve committed spend levels with discount tiers, minimum consumption commitments, and model-tier pricing that can be complex to evaluate without detailed usage data you may not yet have.
What is actually fair about this model
I want to be honest here: I think consumption billing is a more rational model than flat-seat licensing for AI tooling, even though it creates operational complexity.
Flat-seat pricing for AI tools subsidises heavy users with light users. In a large enterprise, that means teams doing serious, high-value AI work are partly paying for teams who have a license but barely use it. Consumption billing means you pay for what you use, which is a better signal for understanding where AI is actually delivering value.
It also unlocks access. A flat-seat model forces you to decide upfront who gets access. A consumption model lets you give broad access and observe where usage concentrates, which is often more valuable for understanding adoption than any survey or internal roadmap exercise.
The problem is not with the model itself. The problem is that most enterprise teams are not ready for it operationally, and the tooling vendors have not done enough to help.
What you actually need to do about it
If your organisation is adopting AI tooling at scale, a few things are worth getting right before consumption billing catches you off guard.
Instrument everything from day one. Every AI service call should be tagged with at minimum: the team or business unit, the use case or workflow, the model version used, and the timestamp. This is not onerous if you build a thin shared client library that every team uses to make AI calls. It becomes very onerous if you try to retrofit it after the fact when your first large bill arrives.
Model your heavy use cases explicitly. Identify the workflows in your firm that involve large context windows, agentic patterns, or high-frequency calls. Estimate token consumption for those specifically. Light conversational use cases will not drive your bill; the edge cases will.
Negotiate committed spend, not seat count. When talking to AI vendors, push the conversation toward committed token or credit volume with defined pricing tiers rather than seat-based licensing. You get better rates on committed spend, and you have a ceiling to budget against.
Build in budget alerts. Both the major cloud providers and the AI API providers offer spend alerts. Set them at levels that trigger human review before they trigger a surprise at month end.
Consider a token budget layer for internal teams. If you are running a shared AI service, implement per-team token quotas with monitoring dashboards. This is the same problem as cloud cost management and the same solution works: give teams visibility into their consumption, set soft limits with alerts, and hard limits only where strictly necessary.
The longer-term picture
The move to token-based billing is one of several structural changes happening simultaneously in enterprise AI pricing. Model capability tiers are becoming more granular. Caching of repeated context is starting to appear as a pricing lever. Specialised models for specific domains are being priced differently from general-purpose models.
The net effect is that AI cost management is becoming a discipline in its own right, the way cloud cost management became a discipline around 2015 to 2018 as cloud adoption scaled. The organisations that built internal competency in cloud economics early ended up with meaningfully better outcomes than those who treated cloud billing as a finance problem rather than an engineering problem.
The pattern will repeat with AI. The engineering teams that understand token economics, instrument their usage, and architect their workflows with cost efficiency in mind will have a significant advantage over those that discover the problem through an unexpected bill.
I am building that instrumentation layer at my firm right now. It is not glamorous work. But I have sat in enough of those budget meetings to know that having the data when the question gets asked is worth considerably more than explaining afterward why you did not.
