How to Track OpenAI API Costs by Customer (and What Changes When You Add Claude)
We found out the hard way. Account 4,781 in our system was responsible for 41% of our entire OpenAI bill, and we'd been treating AI spend as a single company-wide line item for eight months. We were subsidising one customer for two thirds of a year and had no idea.
The OpenAI dashboard shows total spend, model mix, and daily trends. It does not show which of your customers are running up the bill. That gap is the default for almost every team building with AI. You know what you're paying OpenAI. You don't know who in your product is causing it.
What we tried first: metadata tagging
The OpenAI API takes a user field. Pass your customer ID there and, in theory, you can filter usage downstream. Good idea. Almost never works in practice.
The problem is consistency. Every engineer, on every AI feature, in every part of the codebase, has to pass the right ID every time. Legacy features miss it. A third-party RAG wrapper strips it. Someone ships a new chat flow on a Friday and forgets. Six months later, 40% of your calls are untagged. Partial visibility is worse than none — you start making pricing decisions on a sample you don't realise is broken.
What we tried second: a logging pipeline
The textbook fix is to intercept every API call, log it to your database, join it to the customer table, and build a reporting layer. It works. It also takes a data engineer two to three months to ship, another month to harden, and ongoing maintenance every time you add an AI feature or switch providers.
We went down this road. By the time the first version was running, our bill had grown another 30%. We were spending engineering time building cost-attribution infrastructure instead of the product people were paying for. And we still had gaps: historical data before logging, calls served through wrappers, and — coming up next — Anthropic, which would need its own pipeline.
Then you add Anthropic. Or Google. Or both.
We added Claude for document analysis in Q2. By Q3 our Anthropic bill had overtaken our OpenAI bill. The Anthropic Console shows total spend and a model breakdown. That's it. Same problem, different dashboard.
Anthropic's API takes metadata too, so we tagged it the same way. Same outcome — about a third of calls ended up untagged because the third-party RAG wrapper we used didn't forward the metadata field. Building a second pipeline for Claude meant another two months and a permanent split-brain view: GPT costs in one place, Claude in another, no single answer to "what did this customer cost us this month?" Add Gemini and it gets worse before it gets better.
What actually works without three months of infrastructure
The approach that skips the pipeline entirely is direct provider sync plus a thin attribution layer. Instead of logging calls yourself, you connect your OpenAI, Anthropic, and Google accounts to a service that pulls usage from each, maps it to your customer IDs, and surfaces a single per-customer view across all three. No storage to maintain, no joins to write, no second pipeline when you add a provider.
Once we had that view, the decisions came fast. Three customers were each generating over $1,800/month in AI cost on flat-rate plans — we raised their prices and they stayed. One feature used by 4% of customers was driving 31% of cost — we gated it behind a higher tier. One enterprise account was on $400/month of Claude against a $199 plan; we'd never have spotted that from either provider's dashboard. The bill didn't shrink, but margin on it improved a lot, because we were finally charging in the right rough proportion to what we were actually spending.
That's the problem PerUnit is built to solve — cost attribution by customer, feature, and pricing tier across OpenAI, Anthropic, and Google, with Stripe revenue alongside. If you'd like a sense of the gap before going further, our AI margin calculator gives a useful first read on where your numbers actually sit.