The spend question nobody can answer

There is a question that quietly decides whether an organisation's AI programme grows or gets frozen, and it is not about model quality.

What did the customer support team spend on AI last month?

Most organisations cannot answer it. They can tell you what they paid each model provider in total, because that arrives on an invoice. Breaking that down by team, by project, or by feature is an archaeology exercise involving exported CSVs and a best-effort mapping of API keys to owners — usually performed once, under pressure, during a budget review.

Why it matters more than it sounds

An unanswerable spend question has three predictable consequences, and we have watched all three.

Budgets get frozen rather than reallocated. A finance function that cannot attribute cost cannot move it. The safe response to an unexplained increase is a cap, applied uniformly, which penalises the teams getting value alongside the ones that left a loop running.

The invoice arrives weeks after the decision. Provider billing is retrospective. By the time an anomaly is visible, the thing that caused it has been in production for a month. Nobody debugs a cost spike they learn about in arrears; they just tighten the cap.

Nobody can build a business case. "AI cost us £40,000 last quarter" is not a business case in either direction. "Support automation cost £3,200 and deflected 4,100 tickets" is one. The first number is available everywhere; the second almost nowhere.

Metering belongs at the platform layer

The reason this is hard is structural rather than lazy. Cost data lives with the model provider, identity lives with your identity system, and the mapping between them lives in somebody's head.

The fix is to put metering where the request passes through. Every request through our gateway produces an immutable, priced usage record at the moment it is served — not reconstructed later from an invoice. Because that record is written by the same platform that knows which key, workspace and project the request belonged to, attribution is a property of the data rather than a later join.

That makes "what did this project spend" a query. It also makes spend caps enforceable in the direction that matters — before the money is spent, per key and per project, rather than as an alert after the fact.

The part that is usually a trade-off, and should not be

Here is where most vendors ask you to choose.

To attribute cost precisely, a platform generally needs to record a lot about each request. To protect privacy, it needs to record as little as possible. The industry's usual resolution is a policy commitment: detailed logs, and a promise about who looks at them.

We think that is a false choice, and we have built it as one system rather than two. The usage ledger records identifiers, token counts, model names, timings and routing decisions — everything required to answer a spend question — and is typed so that prompt content cannot enter it. Not as a policy, as a structure. A test in our CI scans every column of every table for a canary string to keep it that way.

So the answer to "can you tell me what my team spent, and are you reading our prompts?" is yes and no, from the same records. Knowing what you spent and not being logged are usually presented as opposite ends of a dial. They do not have to be.

What honest billing looks like

Since we are on the subject of money, our own position, stated before we have a pricing page to argue about.

Pricing is announced at general availability. What we can commit to now is the posture rather than the rate: a platform fee set at 5%, charged transparently on top-ups rather than buried in a spread, usage passed through at a published rate card, and credits that do not expire.

That last point is deliberate. Billing opacity — surprise expiries, unexplained spreads, rates that move without notice — is the single most-cited complaint about the incumbent in this category. Being boring and legible about it is a differentiator, which says something slightly depressing about the market.

The question to take away

Before the next AI vendor conversation, try answering this about your current stack:

If a cost doubled next month, how long would it take you to find out which team, which feature, and which model — and would you know before or after the invoice?

If the answer is "after", the problem is not your model choice. It is that nothing in your architecture is counting at the point where the money is spent.