AI adoption has reached a point where the technology budget can move faster than the finance team. In June 2026, Uber imposed a $1,500 monthly cap per employee for each agentic coding tool after the company burned through its entire annual AI budget in roughly four months.
Uber's experience exposes a problem that simple software licensing models weren't designed for. Agentic AI doesn't consume a fixed amount of software capacity: an engineer can trigger thousands of model calls, large context windows, tool invocations, retries, and extended reasoning during a single development task. FinOps therefore has a new unit to manage: tokens, tied to the workflows that consume them and the business outcomes they produce.
This changes the question from "How many AI licenses do we need?" to "How much intelligence does this workflow actually need, and what should we pay for it?"
AI costs don't behave like SaaS costs
Traditional SaaS gives finance teams a relatively predictable calculation. Ten users might cost $X per month. A larger team costs more. Adding another user doesn't normally cause that person's application to execute thousands of additional compute operations without warning.
Agentic AI breaks that assumption.
An AI coding agent can inspect a repository, read documentation, generate a plan, modify multiple files, run tests, interpret failures, retry operations, call external tools, and continue reasoning until the task is complete. Every step can consume tokens. More autonomy can therefore increase the number of model interactions required to complete a task.
FinOps Foundation research now treats AI spend as a major management category. Its 2026 survey found that 98% of respondents manage AI spend, compared with 63% in 2025 and 31% in 2024. The organization also reports that AI cost management is the top skillset teams expect to develop.
The industry is responding with a new vocabulary around token economics. At FinOps X 2026, the FinOps Foundation described tokenomics as a way to connect the production and consumption of AI tokens with technology costs and business value, and announced work toward a Tokenomics Foundation with the Linux Foundation.
That matters because falling token prices don't necessarily produce falling AI bills.
Cheaper Tokens can still produce bigger bills
Model pricing has become more competitive. OpenAI, for example, currently publishes separate rates for input, cached input, and output tokens across its models, with large differences between smaller and frontier models. Yet enterprises can spend more even while individual tokens become cheaper.
The reason is volume.
Suppose a model becomes 50% cheaper while an agentic workflow generates four times as many tokens because developers now allow it to reason longer, inspect more files, invoke more tools, and retry failed operations. The organization still ends up spending twice as much.
That is close to what the Uber story illustrates. The company's problem wasn't simply that individual AI calls were expensive. Usage expanded faster than the budget model anticipated. TechCrunch reported that Uber had encouraged employees to use AI heavily before the company introduced the $1,500 monthly cap per employee and per agentic coding tool.
Agentic systems make this problem harder because consumption isn't determined only by human activity. A developer may issue one instruction while the agent performs dozens of intermediate operations.
That means counting prompts isn't enough.
The New FinOps Unit is the workflow
A useful AI cost dashboard shouldn't stop at "team X spent $42,000."
It needs to answer what generated that spend.
FinOps Foundation guidance recommends tracking token usage and attributing it to individual AI use cases. The basic distinction is between input and generated tokens, but mature tracking needs to connect usage to applications, teams, environments, and workloads.
For an enterprise AI platform, that might mean tracking:
Business workflow → application → agent → model → tokens → infrastructure → outcome
Consider an internal software-development agent. Its monthly spend could be attributed to repository analysis, code generation, test execution, documentation retrieval, and automated review. A customer-support agent could instead be measured by conversations, escalations, retrieval operations, and resolution rates.
That produces a more useful metric than total token consumption.
A team spending $100,000 to automate a workflow that previously required $500,000 of annual labor has a different financial profile from a team spending $100,000 generating experimental summaries nobody reads.
BCG has described this shift as moving toward a workflow-level operating model where companies need to see what AI activity is happening, shape its cost, and either prove value or reduce the activity.
AI FinOps therefore needs a connection between technical telemetry and business ownership.
Token Budgets need to become runtime policies
Uber's $1,500 cap is easy to understand because it puts a hard boundary around individual consumption. Enterprise platforms need the same idea at more granular levels.
A token budget can exist at the organization, team, application, agent, user, session, or workflow level.
For example, an enterprise could define:
- A monthly budget for each AI application.
- A maximum token allowance for a single agent run.
- A maximum number of tool calls per task.
- A concurrency limit for autonomous agents.
- A daily spend threshold that triggers an alert.
- A hard stop when a workload crosses its approved budget.
AWS's current guidance for agentic AI explicitly recommends consumption ceilings across token budgets, iteration limits, time bounds, and concurrency. The goal is to reject unbounded execution at the system boundary instead of discovering the cost after the invoice arrives.
Google's agentic AI architecture guidance makes a similar point by recommending maximum token limits to prevent runaway sessions and control costs. This is where AI cost management starts looking like infrastructure engineering.
A budget should not live exclusively in a spreadsheet owned by finance. The application should know its budget. The gateway should enforce it. The observability layer should expose it. Engineering teams should see the effect of their architecture decisions in real time.
Model Routing is becoming a Cost-Control Layer
One of the simplest ways to reduce AI spend is to stop sending every task to the most expensive model.
A classification request, document extraction task, formatting operation, or simple coding transformation may not require the same reasoning capacity as a difficult architectural analysis.
Model routing allows an enterprise AI gateway to make that decision.
A smaller model can handle predictable workloads. A stronger model can receive tasks that require deeper reasoning. A request can also be escalated when the first model fails a quality check.
AWS describes this as tiered model routing, where less demanding requests go to a smaller model and only a smaller percentage of workloads are escalated to more expensive reasoning models.
The architecture becomes something like:
Application → AI Gateway → Policy → Model Router → Model
The gateway can evaluate workload type, data sensitivity, latency requirements, token budget, model availability, and quality thresholds before selecting a model.
This also creates room for experimentation. Engineering teams can compare the cost and quality of different models on the same workload instead of selecting a single model for the entire enterprise and accepting its pricing profile everywhere.
Context is a cost driver too
Teams often focus on the price of the model while ignoring the size of the context they send to it.
That can become expensive quickly.
Large repository snapshots, repeated system instructions, long conversation histories, tool definitions, retrieved documents, and oversized tool outputs all increase input tokens. Agentic systems can repeatedly process portions of that context across multiple reasoning cycles.
Google's 2026 guidance for AI coding assistants points directly at context bloat as a source of higher token consumption, latency, and reduced model effectiveness.
Context engineering therefore becomes part of FinOps.
Teams can reduce unnecessary consumption by retrieving only relevant documents, pruning oversized tool results, summarizing older conversation state, limiting repository scope, and setting explicit context budgets.
Caching is another major control.
OpenAI's current API documentation describes prompt caching as a way to reuse unchanged prompt prefixes rather than processing the same context repeatedly. Its pricing page shows cached input being billed at substantially lower rates than ordinary input for several models.
AWS similarly recommends prompt caching for repeated context and says supported workloads can reduce input-token costs through cached processing. For high-volume enterprise workloads, these architectural details can matter more than negotiating a small discount on the model's list price.
Agent Loops need financial guardrails
Autonomous agents introduce another source of unpredictable spending: failure.
An ordinary API call usually ends when the response arrives. An agent can decide that the response wasn't good enough and try again. It can call another tool. It can retrieve more information. It can revise its plan. It can invoke another model.
That creates the possibility of retry storms and runaway execution.
AWS's current agentic AI guidance specifically calls out excessive API calls, failed invocation retries, and always-on infrastructure as cost risks. It recommends per-agent and per-tool metrics, caching, batching, cutoffs, and fallback mechanisms.
A production agent should therefore have a termination policy.
Something as simple as:
Maximum iterations = 12
or
Maximum tool calls = 30
can prevent an otherwise useful agent from turning an operational problem into an unexpected invoice.
More sophisticated systems can combine hard limits with confidence thresholds. If an inexpensive model reaches an acceptable answer, the workflow ends. If confidence drops below a defined threshold, the system escalates. If the agent repeatedly fails, it stops and routes the task to a human.
Cost becomes part of the control loop rather than an after-the-fact report.
Shadow AI makes cost governance harder
There is another side to the tokenpocalypse: employees don't always use the AI tools their companies approve.
Perplexity's September 2026 research on Shadow AI describes a growing gap between corporate AI policies and employee behavior. Its article cites a KPMG survey of more than 48,000 people across 47 countries in which roughly half of employees said they had used AI in ways that violated organizational policies. It also notes that usage caps and inadequate sanctioned tools can push employees toward personal AI accounts.
This creates a strange financial loop.
A company tries to reduce AI costs by restricting its official tools. Employees still need AI to finish their work. Some move to consumer products and pay themselves. Others use unsanctioned tools with corporate data.
The organization may reduce the visible AI bill while increasing security and governance exposure.
Perplexity's analysis makes the broader point that shadow AI can indicate a supply problem: employees often go outside IT because the approved option is too limited, too slow, or unavailable.
Cost governance therefore can't mean simply blocking every expensive model.
If the approved platform is unusable, demand doesn't disappear.
A better Enterprise AI Cost Architecture
Enterprise teams need a control plane that sits between applications and model providers.
The architecture can be relatively straightforward:
Applications
↓
AI Gateway
↓
Policy + Budget Engine
↓
Model Router
↓
LLM Providers / Private Models
↓
Observability + FinOps
The gateway records every request. The policy engine determines what the workload is allowed to do. The router selects an appropriate model. Observability captures token usage, latency, model selection, tool calls, errors, and cost.
That information then feeds back into engineering decisions.
A team might discover that 70% of its requests are simple enough for a smaller model. Another might discover that a particular agent spends most of its tokens repeatedly retrieving the same documents. A third might find that a coding agent's cost comes largely from oversized repository context rather than code generation itself.
Those are architecture problems, not procurement problems.
Google Cloud's current FinOps tooling reflects the same direction. Its 2026 announcements include project-level Spend Caps designed to alert and eventually pause API traffic after configured limits are reached.
AI cost controls are moving closer to the runtime.
What Enterprises should measure
A mature AI FinOps program needs more than a monthly invoice.
Token consumption should be visible by model and workload. Spend should map back to teams and applications. Agent runs should expose tool calls, retries, and execution time. Model routing should show how often expensive models are selected.
Business metrics then sit alongside the technical data.
For a coding agent, that could mean cost per accepted change, cost per completed task, or engineering hours saved. For customer service, it might be cost per resolved case. For document processing, cost per successfully processed document.
BCG calls this broader measure "return on AI," arguing that organizations need to connect AI costs with workflow outcomes rather than treating activity itself as the measure of success.
That distinction matters because high token usage isn't inherently bad.
A $10 workflow that replaces a two-hour manual process may be cheap.
A $0.20 workflow that nobody uses isn't necessarily cheap.
What we see at 0xMetaLabs
AI cost governance is becoming an architecture concern because model consumption is now shaped by application design.
Teams that wait for finance to identify an AI spending spike are already several layers removed from the cause. By the time the invoice shows a problem, the underlying issue may be a prompt that grew over time, an agent that retries too aggressively, a retrieval system that sends unnecessary context, or a workflow that routes every request to a frontier model.
The stronger pattern is to put cost controls into the same architecture that controls identity, security, data access, and reliability.
That means treating token budgets as runtime policy, exposing AI consumption through observability, routing workloads according to their actual reasoning requirements, and giving engineers feedback on the cost of the systems they build.
It also means leaving room for exceptions. A hard ceiling that prevents a critical production workflow from completing can create a different operational problem. Good governance should make expensive behavior visible and intentional rather than simply making it impossible.
The CFO Doesn't Need Fewer AI Tokens. They Need Predictable AI Systems.
Uber's experience provides a useful warning for every enterprise increasing AI adoption: usage can grow much faster than the assumptions behind an annual technology budget.
The response shouldn't be to put every employee on a smaller AI allowance and hope the problem disappears.
AI spending needs engineering controls.
Token budgets, model routing, context limits, caching, agent iteration ceilings, workload attribution, and cost-aware observability give organizations a way to control consumption without freezing adoption. FinOps and Tokenomics are converging on the same question: how much intelligence is a workload consuming, what does that intelligence cost, and what outcome does it produce?
That is the difference between an AI program that merely has a budget and one that can operate inside it.
For enterprises building this layer now, the next step is to map AI consumption to individual workflows and identify where model choice, context size, agent behavior, or missing runtime limits are driving the bill. Once those relationships are visible, cost stops being a surprise at the end of the month and becomes another engineering parameter that can be designed, measured, and controlled.
