AI Token Spend 101: A Finance Leader's Guide to Understanding (and Managing) Usage-Based AI Costs

AI spend is a new frontier for finance, here's how to chart it

Managing software spend was never simple. Agreements scattered across inboxes, auto-renewals nobody tracked, vendors that always knew more about your contracts than you did. But at least the number was knowable: you bought seats, you signed an order form, and the price was written in the document.

AI is a new frontier. The fastest-growing line on your software P&L is now metered by the token, billed after the fact, and capable of multiplying month over month, sometimes day over day. Enterprise spending on generative AI models and agents is on track to more than double this year, according to Gartner. 

The line that's exploding is also the line finance has the most trouble seeing clearly.

This guide is written for the finance, FinOps, and procurement leaders trying to get a handle on AI token spend. How to understand it, how to track it, how to (attempt to) forecast it, and ultimately how to manage it. It explains, in plain terms, what you're actually paying for, why the bill is so hard to predict, and a repeatable framework for baselining and forecasting AI costs, so you can plan around them instead of reacting to them.

Key takeaways

• Tokens are the new unit of cost. AI vendors bill by input and output tokens, not seats. Output tokens typically cost around five times input tokens — sometimes more — so verbose responses and chatty agents drive the expensive side of the bill.
• The problem is classification, not just tracking. You can't forecast what you can't categorize. The first job is sorting every AI dollar into subscription, usage-based, or hybrid at the agreement level, not the vendor level.
• Usage-based pricing hides inside "normal" software too. It's more than just your model bill; it's the clouds, the aggregators, and the metered AI features now embedded in tools you think of as flat subscriptions.
• How you forecast AI depends on where it lands. AI spend that directly serves your customers is COGS and scales with customer usage — which only tracks revenue if your pricing does. AI spend that makes your team faster is OPEX and scales with adoption. Different curves, and neither is linear.
• A baseline + guardrails beats a spend freeze. The end goal is to know exactly what you spend, what it buys, and what it will cost next quarter. 

What is AI token spend, and why should finance care?

AI token spend is the cost of running large language models, billed by the volume of text they process. A token is a small chunk of text, roughly ¾ of a word in English. Every time someone sends a prompt or an AI returns an answer, the model counts the tokens going in (input tokens, your prompt and context) and the tokens coming out (output tokens, the response), and charges per million tokens at a rate that depends on the model.

The basic formula is simple:

Cost = (input tokens × input price) + (output tokens × output price)

What makes it a finance problem rather than an engineering footnote is three things. 

• First, output usually costs several times more than input, so the length and verbosity of answers, not just how often the tool is used, drives spend. 
• Second, the "smartest" model can cost 5x or more than a still capable, but cheaper one, which means the same task can carry wildly different price tags depending on which model handles it. 
• Third, consumption is unbounded by headcount. A single engineer running coding agents overnight can consume more tokens than an entire department of human typing ever could.

This is why CFOs are increasingly treating AI as its own line in the P&L. As Deloitte put it in its CFO guide to governing the AI P&L: "tokens — not licenses or headcounts — are becoming the true unit of cost."

Not all tokens cost the same: matching the model to the job

A token is not a fixed price. Every provider offers a ladder of models, and the price per million tokens can differ by 10x or more from the bottom of the ladder to the top. 

Three things move the rate:

• Model tier: Flagship "frontier" models (the most capable) cost multiples of the smaller, faster models in the same family. The same prompt can cost a few cents or a few dollars depending only on which model answers it.
• Input vs. output: Output tokens typically run several times the price of input tokens, so a model that's chatty or "thinks out loud" at length costs more than its headline input rate suggests.
• Reasoning and context: Reasoning/extended-thinking modes generate far more (billable) output to work through a problem, and very large context windows mean more input tokens per call. Both raise the per-request cost.

The practical takeaway is that model choice is a spend lever, not a technical detail. Most tasks don't need the most expensive model. The default should be to route the work: small, cheap, fast models for high-volume, low-complexity jobs (classification, routing, extraction, summarization, simple drafting), and the frontier models reserved for genuinely hard reasoning, complex code, or ambiguous problems where the quality difference pays for itself. This is what teams mean by a "model router," and it's one of the highest-leverage cost controls available.

Two cautions for finance

• First, cheapest-per-token isn't always cheapest-per-outcome: a weak model that needs retries, longer outputs, or human cleanup can cost more in total than the capable model that gets it right once. Judge by cost per completed outcome, not sticker rate. 
• Second, your model mix is itself a forecasting variable: if usage shifts toward pricier models (or a team quietly defaults everything to the flagship), the bill rises even when token volume doesn't. Tracking which models are running the spend is part of understanding the bill.

Why is AI spend so hard to predict?

Because the pricing model changed underneath you. Three shifts, in particular, make AI spend behave nothing like the software contracts finance is used to.

1. Usage-based pricing replaced the fixed seat

Seat-based SaaS was predictable by design: a known number of users at a known annual rate. Usage-based (consumption) pricing meters what you actually use (tokens, API calls, agent tasks, documents processed) and bills after the fact. The upside is you only pay for what you use. The downside, in finance terms, is that the invoice is no longer a number you set; it's a number you discover.

The discovery can be brutal. TechCrunch reported in June that Uber exhausted its entire 2026 AI coding-tools budget by April, and that a routine Cursor contract renewal at Priceline came back 4–5x more expensive. Spend alerts and bill-shock warnings are now a standard feature category, because the alternative is finding out from the invoice.

2. AI spend comes in five flavors, and only one is obvious

The bill everyone pictures, the direct model invoice, is only the first flavor. The other four are where finance gets surprised:

1. Model providers. The frontier labs themselves — Anthropic, OpenAI, Google, xAI — plus the agents built directly on their APIs. These bill on token consumption, and they're the spend most people mean when they say "our AI bill." They're also the most visible flavor: the invoice at least says what it is.
   
   
2. Clouds. The same frontier models, consumed through a hyperscaler — Amazon Bedrock, Azure AI Foundry, Google Vertex AI, Cloudflare Workers AI. Here the AI spend dissolves into a much larger cloud bill, engineering owns the account, and finance may never see a line that says "AI" at all. The billing unit isn't even consistent: Cloudflare meters Workers AI in its own unit, Neurons. This is also where forgotten deployments quietly keep running — the old model nobody deprecated, still metering away inside the cloud invoice.
   
   
3. Aggregators. Gateways like OpenRouter that route requests across hundreds of models through one API key, with routing fees stacked on top of model costs. Convenient for engineering; opaque for finance, because one charge now blends many providers' rates.
   
   
4. AI-native apps. Products built around AI as the core value — coding tools like Cursor, AI search, AI analytics, meeting assistants. The user often picks the model inside the product, which makes spend attribution nearly impossible from the outside, and pricing is frequently a hybrid of seats plus consumption credits.
   
   
5. Bolt-ons inside pre-existing SaaS. The CRM with AI assist, the support platform charging per AI resolution, the design tool that changed its AI policy, the dev tool that quietly moved to per-token billing. The base contract still looks like a flat subscription, but a consumption meter now runs inside it.
   
   

The "surprise" AI spend usually hides where finance least expects it: inside the cloud bill, inside the aggregator's blended charge, and inside the consumption riders and metered add-ons buried in agreements you treat as flat subscriptions. If your inventory only flags the tools with "AI" in the name, you're missing most of the exposure.

In fact, across all agreements in BRM — the entire software stack, not just the obvious AI vendors — 4.3% already carry both a committed fee and a usage-based component explicitly tied to AI. 

One in every twenty-three contracts a company signs now has an AI meter running inside it.

3. The same vendor can bill three different ways

This is the subtlety that wrecks most spreadsheets. A single vendor relationship often contains several commercial models at once. An Anthropic relationship, for example, might be API credits (consumption, topped up irregularly), a Team plan (seats), and Max and Pro plans on individual cards — each behaving completely differently in a forecast. On a card statement, a $30K "Anthropic" charge could be a predictable subscription renewal or a one-time credit purchase that recurs at an unpredictable cadence. They look identical. They are not.

And because these are contract structures, the bill can change without usage changing at all. When GitHub moved Copilot to metered AI billing in April, the billing multiplier on Anthropic's Opus jumped from 7.5x to 27 overnight. Crossing a seat count or committed-spend tier can flip an entire agreement from bundled usage to raw metered rates the same way. No receipt warns you about that. It lives in the contract.

How do I get a handle on my AI spend? (A six-step framework)

Getting control of AI spend is a sequence. Here's the order that works.

Step 1: Inventory every AI line item, across all five flavors

List every vendor with an AI component — the model providers, but also the cloud accounts running hosted models, the aggregators, the AI-native apps, and the AI-enabled tools whose base contract looks like ordinary SaaS. Pull from your card statements, your AP records, and, critically, the executed agreements themselves, because that's where the consumption clauses hide. The goal of this pass is completeness, not precision.

Step 2: Classify each agreement by commercial model

For every agreement, label it: flat subscription, seat-based, usage/metered, or hybrid (a subscription with a consumption rider). Do this at the agreement level, not the vendor level. Remember that one vendor can be several models at once. The output of this step is your consumption exposure map: the list of line items where the bill is a variable, not a constant. This is the single most valuable artifact in the whole exercise.

Step 3: Establish a baseline

For the usage-based lines, capture the last 3 to 6 months of actual consumption and the attributes that explain it: ideally model, feature, team, and input vs. output split. Every major provider exposes this through an admin or cost API — usage by model, API key, project, or user — which gives you real granularity from day one if you connect to it. For embedded AI features, the vendor's usage export is your source. The baseline is the run-rate you'll forecast from.

Step 4: Attribute spend to teams and outcomes

Allocate consumption to the team, product, or workflow driving it. This is the chargeback view that turns "the AI bill went up" into an accountable conversation. It also surfaces the uncomfortable but useful truth that some spend is clearly worth it (engineering coding agents that save more than they cost) and some isn't (tools nobody uses, narrated agent steps, the most expensive model doing a job a cheaper one could do).

Step 5: Forecast with volatility built in

Do not draw a straight line. AI spend is a variable input cost, and what it varies with depends on the classification you did in Step 2 and the COGS/OPEX split covered below: customer-serving spend scales with product volume; internal-productivity spend scales with adoption. Project the usage-based lines from actual consumption velocity, layer in known step-changes (a new agent rolling out, a pricing tier you're about to cross, a seasonal volume spike), and model a range (best case, likely, worst case) rather than a single number. Anomaly detection that flags spend deviating from the expected range is worth more here than a tidy annual figure.

Step 6: Set guardrails, not just budgets

Close the loop with controls: per-team token budgets, real-time threshold alerts, approval gates for high-consumption usage, and (on the engineering side) model routing so cheaper models handle simpler tasks. The aim is to make spend visible and accountable before the invoice arrives, not to freeze it. Visibility comes first; the savings decisions follow from it.

How do I establish a baseline and forecast AI costs into the future?

Once spend is classified (Step 2) and a run-rate exists (Step 3), forecasting becomes a tractable modeling problem. Three principles separate a forecast that holds from one that's obsolete by month-end:

Forecast the variable lines separately. Subscriptions you can project with a calendar. Usage-based lines you project from consumption trend. Mixing them into one blended number is how budgets get blown, because the predictable part masks the volatility of the variable part.

‍Tie costs to a unit of business value. The strongest AI forecasts express cost per outcome (cost per resolved support ticket, per processed document, per completed agent session), not just cost per token. Unit economics lets you answer the question leadership actually cares about: is this spend producing proportional value, and what happens to the bill as volume grows?

Re-baseline often. Per-developer token consumption rose roughly 18.6x in nine months, according to research from Jellyfish reported by TechCrunch, driven largely by agentic tools. Goldman Sachs projects global token usage will multiply roughly 24-fold by 2030. In that environment, a forecast set once a year is fiction. Treat the model as living, and revisit it every quarter against actuals.

This is exactly the shift the FinOps community formalized this year. J.R. Storment, executive director of the FinOps Foundation, told TechCrunch he started hearing the same alarm from companies this spring — "we are 3x over our entire 2026 token budget, and it's only April" — and that the whole conversation shifted from tokenmaxxing and "go fast" to guardrails and control.

Is your AI spend COGS or OPEX? And how do you tell them apart?

One classification matters more than any other for how your business is judged: whether a given dollar of AI spend is cost of goods sold (COGS) or operating expense (OPEX). The token bill is the same either way, but where it lands on the income statement changes your gross margin, your unit economics, and how investors read the company.

The dividing line is simple to state: if the AI spend is incurred to deliver your product to a paying customer, it's COGS. If it supports the business but isn't part of what you sell, it's OPEX.

• COGS (cost of goods sold). Token spend that scales with usage of your product: the model calls behind an AI feature your customers use, inference that serves customer requests, the LLM powering your support bot or in-app assistant. This sits above the gross-margin line and directly compresses gross margin as customers use you more.
• OPEX (operating expense). Token spend that makes your team more productive but isn't embedded in the product: coding assistants for engineering (typically R&D), an internal copilot for the go-to-market team (S&M), AI in finance or legal workflows (G&A). This sits below the gross-margin line.

This split also determines how the forecast behaves. For AI-native companies, the defining feature is that a material share of token spend is COGS: it scales with customer usage, so you forecast it like unit economics — and it only tracks revenue if your pricing does. When customers consume more inference than their contract prices in, usage growth compresses gross margin, which is exactly why the COGS line is the one to watch. That's on top of the same internal AI spend every company has; an AI-native company's engineering team can burn as many tokens building the product as the product burns serving customers. 

For established companies adopting AI internally, nearly all token spend is OPEX: it scales with employee adoption, agent rollouts, and above all intensity — agentic tools mean each person's consumption can multiply even when the team doesn't grow — so the forecast drivers are adoption curves and consumption per person, not revenue. Same tokens, different curves. A forecast that doesn't know which curve each line is on will be wrong in both directions.

The trap is that the same vendor, even the same monthly invoice, can be both. Your Anthropic relationship might include a production API key serving your customer-facing feature (COGS) and a set of Claude seats your team uses internally (OPEX). At the vendor level, they're indistinguishable. You can only split them at the level of the individual agreement and the individual usage line: which API key, which workload, which team, which feature.

To differentiate and report on it: tag each usage-based line by its driver. Production / customer-serving workloads (an API key wired into your app, inference tied to customer volume) map to COGS. Internal-productivity workloads (developer tooling, internal assistants, back-office automation) map to OPEX, then sub-allocate to R&D, S&M, or G&A by the team that consumes them. Provider admin APIs expose spend per API key, project, or user — exactly the granularity you need to draw the line. Once every line carries a COGS-vs-OPEX tag and a department, you can report the AI portion of gross margin separately from AI operating cost, and watch the COGS line specifically, because that's the one that moves your margin as you grow.

This is also where vendor-level tooling breaks down again. A receipt categorized to "Anthropic" can't tell you which share served customers and which served staff. Classifying at the agreement and line-item level, and tagging each line to COGS or OPEX with a department, is what makes a clean gross-margin story possible.

What questions should finance ask about every AI vendor?

Before you sign or renew, this checklist surfaces the clauses that turn into surprises later:

• Is this agreement subscription, seat-based, usage-based, or hybrid?
• If there's a consumption component, what's the unit (tokens, API calls, tasks, documents — or something proprietary, like Neurons) and the rate?
• Is there committed/bundled usage included, and what happens when we exceed it: overage rates or a hard cap?
• Are there thresholds (seat counts, spend tiers) that change the commercial terms if we cross them?
• How do we get usage data (per user, per API key, per team), and how often? (This is also what lets you split the spend between COGS and OPEX.)
• Can we set spend limits or alerts on the vendor side?
• How does the price scale, and what's our projected cost at 2x and 5x our current volume?

Common mistakes finance teams make with AI spend

• Tracking receipts without modeling the contract. A receipt tells you what you paid; it can't tell you whether that's inside your commitment, past it, or about to reprice. The "why" lives in the agreement.
• Classifying at the vendor level. Lumping all "Anthropic" spend together averages subscriptions and credits into a number you can't forecast. Classify per agreement.
• Forecasting AI like fixed overhead. Linear projections built for stable infrastructure badly underestimate variable, adoption-driven AI growth — and ignore whether the line scales with revenue (COGS) or with headcount (OPEX).
• Measuring cost without measuring value. Capping spend blindly destroys the high-ROI uses along with the wasteful ones. Pair spend visibility with outcome data.
• Only watching the obvious AI vendors. The hosted models inside your cloud bill, the aggregator charges, and the metered features inside your "normal" SaaS are where exposure quietly compounds.

Where AI spend visibility usually breaks down

Notice that almost every step above depends on one thing: knowing the commercial model behind each charge. That's also where most tooling falls short. Spend-management platforms are excellent at capturing receipts and categorizing them by vendor, yet a receipt categorized by vendor still can't tell you whether a charge is subscription or credits, inside commitment or past it, fixed or about to reprice. And no receipt exists at all for the model spend running inside your cloud accounts. The information finance needs to forecast lives in the agreement and in the provider's own usage data, well below what a card statement can show.

This is the gap BRM was built to close. BRM treats the agreement as the source of truth and resolves everything else (receipts, transactions, renewals, provider usage data) back to it. The result is the one thing the spreadsheet and the card statement can't give finance: a structured, queryable model of what you're actually paying for, decomposed to the level where the decisions get made.

How BRM gives finance the full picture

A live AI spend view, from data you already have. Every BRM customer gets a pre-built, always-current view of AI spend across the whole stack: run rate, trend by vendor, month-over-month acceleration, usage-based charges split from seat-based plans. BRM builds it from the systems where the spend already lives — cards, expense management, ERP, email, and your agreements — with no manual tagging. An Anthropic relationship splits into API credits, Team, Max, and Pro, each on its own line. You see what's metered and likely to move, apart from what's fixed.

Direct, API-level integrations with the providers themselves. For the deepest layer — model family, input and output tokens, spend by model, key, and team — BRM connects directly to the providers' own usage and cost APIs. These integrations are live today across all five flavors of AI spend: Anthropic, OpenAI, and xAI among model providers; AWS Bedrock, Azure AI Foundry, Google Vertex AI (Gemini Enterprise Agent Platform), and Cloudflare Workers AI among the clouds; OpenRouter among aggregators; and Cursor among AI-native apps — with more coming. Every connection is read-only and scoped to usage and cost data.

The spend below the waterline, surfaced. The cloud integrations make the invisible flavors visible. AWS: Bedrock per-model spend, plus the Marketplace agreements (including private offers) that never reach procurement. Azure: a year of daily spend history, backfilled by resource and meter. Vertex: per-model usage and spend, down to Claude billed as its own line items. Cloudflare: Neurons converted to dollars, free tier tracked. No card statement will ever show you any of this.

Commercial model on every agreement and line item. BRM's agents collect the receipts, invoices, and executed agreements already sitting in your inbox — no integration, no engineering ticket — and resolve every charge to the agreement it belongs to. Each agreement carries its commercial model as a first-class fact: seat-based, subscription, usage, or hybrid, classified at the line-item level because one vendor is routinely several models at once. The subscription receipt lands on the seat agreement; the credit top-up lands on the usage agreement. Subscription, credits, and overage separate automatically.

Everything downstream becomes a query. The consumption exposure map from Step 2: show me every agreement with a usage-based component. The COGS/OPEX split: tag each line by driver and department. The forecast: project the variable lines from real consumption velocity. And because BRM connects to Claude over MCP, "how much of last quarter's Anthropic spend was credits vs. seats?" is a question you can simply ask.

Why other tools can't match this. Spend-management platforms are built around the receipt: they know the total, not the commercial model behind it — and they can't see inside the cloud bill at all. Engineering observability tools model token cost in exquisite detail, but they live in traces and serve engineers. BRM sits at the intersection both miss: the commercial truth of the contract, reconciled against the receipts and the providers' own usage data, in the language finance already uses.

Your AI vendors can see exactly what you're consuming, in real time, by model and by key. Now you can too. 

‍

That’s how we bring power to the buyers.

‍

Want to see it live? Book a demo

‍

Next, learn why the era of tokenmaxxing gave way to token accounting — see our companion piece, Tokenmaxxing is dead. Long live valuemaxxing.

Frequently asked questions

What is the difference between token-based and seat-based pricing?

Seat-based pricing charges a fixed amount per user, so the bill is predictable and set in advance. Token-based (usage-based) pricing charges for what you actually consume (measured in tokens of text processed), so the bill is variable and known only after the fact. Many AI vendors now blend both in a single hybrid agreement.

How much should a company budget for AI token spend?

There's no universal number because it scales with usage, not headcount. The right approach is to baseline 3 to 6 months of actual consumption per usage-based agreement, express it as a run-rate and a cost-per-outcome, then forecast a range that accounts for adoption growth and any pricing thresholds you might cross. Budget the variable lines separately from your fixed subscriptions.

Why did our AI bill suddenly increase without more usage?

Most often, a clause in the agreement triggered: you crossed a seat count or spend tier that converted bundled usage to metered rates, exhausted included credits and moved into overage pricing, or a vendor changed its billing model — as happened when GitHub moved Copilot to metered AI billing and model multipliers jumped overnight. Because these are contract events rather than usage events, they don't show up as a usage spike; they show up as a higher invoice.

Is usage-based AI pricing cheaper than a subscription?

It depends entirely on your consumption pattern. For light or spiky usage, paying only for what you use is cheaper. For heavy, steady usage, a committed subscription or bundled plan is often far cheaper than metered rates. The discipline is matching the commercial model to your actual usage profile, which you can only do once you've classified and baselined your spend.

How do I track AI spend across multiple vendors?

Start with a complete inventory that covers all five flavors — model providers, clouds, aggregators, AI-native apps, and AI-enabled tools — then classify each agreement by commercial model, and centralize the actuals so subscriptions and consumption are reported separately. The key is resolving each charge to the agreement that explains it, and pulling usage from the providers' own APIs, rather than stopping at vendor-level totals.

Curious where your own consumption exposure sits? BRM maps every agreement to its commercial model, connects directly to your AI providers, and reconciles your receipts against all of it — so finance can see what's usage-based, what it costs, and what it'll cost next quarter. We'd be happy to show you how.

‍