The problem: nobody can answer "what does our AI cost?"
Ask a team using AI seriously what it costs them per month and you'll usually get an invoice total — the sum of a few subscriptions plus whatever the API bill was. It's a real number. It's also close to useless for every decision you'd actually want to make with it: whether a workflow is worth automating, which assistant is earning its seat, whether last week's spike was a problem or a rounding error.
The invoice total fails in both directions at once. It overstates the cost of work done inside a flat subscription you're already paying for, because that work had no marginal cost at all. And it understates — or entirely hides — the per-token spend that grows with usage, which is the only part that can actually run away from you. Two errors pointing opposite ways don't cancel out; they just produce a number nobody can reason about.
This guide is the model that fixes it. Three buckets, then the four traps that corrupt the math even when the buckets are right. None of it is specific to any one tool — it's how to think about the question, and you can apply it with a spreadsheet this afternoon.
The three buckets
Every AI dollar you spend belongs to exactly one of these. Sorting your spend this way is most of the work.
Fixed. Flat monthly subscriptions — a coding-agent plan, a team chat plan, an editor seat. You pay the same whether you use it once or ten thousand times. Each of these carries an included value: the usage the fee already covers.
Variable. Per-token or per-call spend, billed by whatever gateway routed the request. This is the only bucket that moves with how much you use it, which makes it the only bucket that can surprise you.
Excluded. Usage that genuinely costs the thing you're measuring nothing. Two common cases: requests made with someone's own API key (their provider bills them, not you), and models running locally on a laptop or a self-hosted box. Excluded is not the same as free — someone is paying, or paying in electricity. It's a statement about whose ledger the cost lands on.
The reason this split earns its keep: only the variable bucket responds to usage. Once you can see it in isolation, "our AI spend jumped" becomes a question with an answer instead of a shrug.
Covered vs. overage is where the insight is
Inside the fixed bucket, split usage into what the subscription covered and what spilled past it into overage.
Covered usage has zero marginal cost. That is the whole proposition of a flat plan, and it means a heavily-used subscription is not an expensive one — it's the opposite. A plan you're at 30% of is the expensive one, per unit of work.
Overage is different in kind, not degree: it's per-token spend that happens to be attached to a subscription, and it belongs in your variable thinking. Teams that don't make this split end up with two failure modes — panicking about heavy usage that cost nothing, and missing overage that quietly became the largest line on the bill.
Four traps
The buckets are the easy part. These are what corrupt the number even when the buckets are right, and all four are quiet — none of them throws an error.
1. Double-counting a covered subscription. You pay the flat fee, then also add an estimated per-call cost for the requests that fee already covered. Now the same work appears twice. The rule: for a covered request, the fee is the only dollar. Estimate a per-call price for it if you want attribution, but never add it to a total that already contains the fee.
2. Pricing local models at cloud rates. This one is genuinely sneaky. Local runtimes commonly expose model identifiers shaped exactly like cloud catalog names, so a cost lookup that falls through to a public price table will confidently price your free local inference at cloud rates — and the number it produces looks completely plausible. Local usage has to be zeroed before it reaches any price lookup. Ordering is the whole fix; a correction afterward means the wrong number already got written down somewhere.
3. Mistaking telemetry for billing. It's useful to estimate the token cost of every tool call from its payload size. It is not a bill. Those estimates are diagnostics — they tell you which operations are heavy. Summing them into a cost report produces a number that no invoice will ever agree with, and you will spend a genuinely unpleasant afternoon trying to reconcile it.
4. Treating estimates as actuals. Some gateways return the exact cost of a call; others don't, and you infer it from token counts. Keep the two labelled and never add them into one figure. Estimates are fine for spotting trends and attributing spend; only actuals should back a number you report upward or reconcile against a statement.
Building the picture yourself
If you want this without new tooling, in rough order of payoff:
- List every AI line item and tag it fixed, variable, or excluded. Most teams find something in the excluded bucket they'd been counting, and something variable they'd never looked at.
- For each fixed subscription, write down its included value and which tools or clients it covers. This is what lets you compute covered vs. overage instead of guessing at it.
- Find the per-token spend that isn't attached to any subscription. This is the bucket that can grow without anyone deciding it should.
- Attribute the variable bucket by surface — which assistant, which tool, which day. An unattributed total tells you that spend happened, not where to intervene.
- Mark every figure as actual or estimated. If you can't say which a number is, you can't defend it.
- Set a ceiling before you need one. A budget limit is worth far more configured while things are calm than discovered during a spike.
That's a spreadsheet, and a spreadsheet genuinely works — right up until it needs to be current, at which point somebody has to maintain it by hand every week, and they won't.
Getting it without the spreadsheet
This model is how GreatArrow.ai accounts for AI spend internally, which is why it's also what the product reports back to you. Every generative and embedding call routes through one path and is logged once, so the picture doesn't depend on anyone remembering to write something down.
What that gives you: per-AI spend broken out by connected assistant, tool, and day; budget ceilings you set per workspace; and cheapest-capable-model routing so the variable bucket stays smaller by default. Registered subscriptions get split into covered versus overage automatically, so the fixed bucket stops lying to you. Bring-your-own-key and local-model usage are tracked but excluded from platform cost, with the fallback case handled correctly rather than silently. And because the same data reads identically on the web and over MCP, you can ask a connected assistant what last week cost instead of opening a dashboard.
Cost is one of the four things a shared memory layer is for — the other three being knowing your business, doing the work, and controlling who sees what. Start at /sign-up if you want the reporting without building it; a free trial tier is available and no credit card is required.
Where to go next
If the reason your AI spend is hard to see is that it's scattered across four assistants that don't share anything, One Memory Across Every AI Client covers the underlying problem. For the evaluator-level view of the protocol that makes a single reporting surface possible across different clients, read What Is MCP? A Guide for Teams.