You cannot bill a customer for a number you had to guess

A customer asks what their AI usage cost last month. You have exactly one number: the provider invoice. It does not split by customer, by feature, or by user. So you guess — and you either eat margin quietly or overcharge somebody who will eventually check.

I did this for three years across about a dozen client projects, and the cost conversation went the same way every time. It never came up during the build. It came up in month two of production, from finance rather than from engineering, and by then the architecture that would have made it answerable was already three months behind us.

Why the invoice cannot answer it

Your provider bills you for tokens. Tokens are attributed to an API key. You have one key, or a handful, and they are shared across every customer in your product, because that is the sane way to run a service.

So the invoice tells you the truth about your total and nothing about its shape. Which is fine until any of these happen:

• A customer on your $200 tier uploads a 900-page PDF and asks forty questions a day about it.
• You add a feature that quietly triples average tokens per turn, and revenue does not move.
• An enterprise prospect asks for usage-based pricing and you have no per-account usage.
• Someone asks which of your features is unprofitable, and the honest answer is that you cannot tell.

You can bolt on token counting after the fact. Most people do. You wrap the provider client, log usage per request, stamp it with whatever request-scoped identifier you have handy, and write it to a table. It works, and it is about two weeks of work, and then it drifts — because the counting lives in your application code and every new call path is a new place to forget.

The deeper problem is that request-scoped identifiers are not customer identifiers. A background job has no request. A retry has a different one. A scheduled run at 3am has no user in scope at all unless you deliberately carried one there, and "deliberately carried one there" is exactly the thing that gets dropped in the third refactor.

Attribution as a property of the call

The version that does not drift is the one where the thing spending the money already knows who it is spending it for.

In Oberik every data-plane call carries a token, and the token carries a subject and a tenant. That is not primarily a cost feature — it is the isolation boundary, the same claim that decides which documents the call may see. But it means spend, latency and traces are sliced per project and per end-user as the calls happen, rather than being reconstructed from an invoice afterwards.

A scheduled run inherits it too. Every task runs as the subject that created it, with that subject's visibility — which is a security property first (a scheduled run can never see more than the user could see themselves) and an accounting property for free.

The practical difference is what "what did this customer cost" becomes. Not a data engineering project. A filter.

The other half: whose bill is it

The design decision I was most stubborn about is that Oberik does not sit between your customers and their model provider.

You register your own provider keys per project. Requests route through your credentials, and the usage is billed to you, by your provider, at your provider's price. Nothing resold, no markup, no metering of ours on top.

curl -sX POST "https://oberik.com/api/projects/$PROJECT_ID/providers" \
  -H "X-API-Key: $PROJECT_KEY" -H "content-type: application/json" \
  -d '{"provider":"openai",
       "models":["gpt-4o-mini","text-embedding-3-small"],
       "values":{"api_key":"sk-…"}}'

There are three reasons for this and only one of them is philosophical.

The philosophical one: I did not want to be another company standing between you and your model provider, taking a cut of a commodity. That layer has never made a product better.

The practical one: your customers increasingly have opinions. Some are on Azure because procurement said so. Some are on Bedrock because of a data residency clause. Some have a negotiated rate with Anthropic that is better than any list price you could resell them. A vertical AI product that cannot say yes to "we need this to run in eu-central" loses deals it never hears about.

The third: it makes the cost number honest. When the traffic runs on your key, the platform's own number and your invoice are describing the same events. If we resold tokens, our number would be our margin model and your invoice would be a different fiction, and reconciling them would become somebody's job.

What you actually need before you can price

Three numbers, and most teams have none of them in month one.

Cost per customer per month. Obvious, and the one everyone asks for first.

Cost per turn, distributed. The mean is nearly useless here. What you want is the tail — the p95 turn, and what makes it expensive. Usually it is a long retrieval with a large context, or a tool loop that went eleven iterations. max_tool_iterations is a claim you can put on a token, which is a blunt instrument but a real one.

Cost per feature. Not per endpoint. Per thing your customer thinks they are buying. Retrieval, sandbox, scheduled work, and document ingestion are four very differently-shaped costs, and ingestion is the one that surprises people: a 200-page report with two scanned exhibits should cost two pages of OCR, not 200. Every document reports read_with, pdf_type and ocr_page_count, so "why did ingesting these cost what it did" is a field rather than an argument.

One detail there worth knowing: a failed document reports those three as well, and they mean the same thing. A page sent to OCR that came back empty is still a page you were billed for.

The unglamorous conclusion

None of this is interesting work. Nobody has ever demoed cost attribution. It is the kind of thing that shows up in an architecture decision made in week two and then either quietly works for four years or quietly does not.

But it decides whether you can sell usage-based pricing, whether you can answer an enterprise procurement questionnaire, and whether you find out about the customer who is costing you 40× the median before or after your quarter closes.

If you are building AI into a product you sell to more than one company: decide now who the spend belongs to, and make the call that spends the money carry that identity. Everything else about it is easy afterwards, and nothing about it is easy before.

Free while we launch, and your own keys throughout. oberik.com