Tracking AI Costs Across OpenAI, Anthropic, and Gemini for One Customer

Two providers, one customer, and my numbers didn't add up. The chat feature ran on one model. The document parser ran on another. Both bills came at the end of the month, in different formats, at different rates, and neither one had "Customer A" written anywhere on it.

If your product uses more than one AI provider, and by 2026, most do, you've probably already figured out how to track AI costs across OpenAI, Anthropic, and Gemini at the account level. The provider dashboards show you what you spent in total. But they can't tell you what one customer cost you across all three bills. That's the number that actually matters for pricing decisions, and it's the one nobody else is explaining how to get.

I've already written about how to attribute AI costs to individual customers when you're using a single provider. That post covers the base habit: label every AI request with the customer who triggered it, record the usage, price it, and group it by customer. Everything in this article builds on that foundation. If you haven't read it, start there; it's the first half of the equation. This post is the second half: what changes when one customer's usage is spread across two or three providers that don't charge the same way.

Why "Multi-Provider" Breaks Simple Per-Customer Tracking

The single-provider version of this problem is straightforward. You label every AI request with a customer ID, just a unique tag your software uses to recognize which customer triggered the request, and you price each request using your provider's rate. Then you add it all up per customer.

That habit still works. But once your product routes requests to more than one provider, a new problem shows up: each provider uses different pricing, different billing formats, and sometimes even different units. So when I try to add up what Customer A cost me this month, I'm combining numbers from billing systems that don't speak the same language.

This isn't just an engineering inconvenience. It's a business visibility problem. If I can't produce one reliable cost number per customer, I can't calculate that customer's real margin. And I definitely can't price my plans accurately.

The Three Things That Are Actually Different Between Providers

It's easy to assume that switching from one AI provider to another is like switching between two similar vendors, mostly the same, with minor differences. In practice, three things make multi-provider AI cost tracking genuinely complicated.

Different Rates

Every provider charges per token, small chunks of text that the AI model reads and writes. But the price per token varies widely. Here's an approximate snapshot using one representative mid-tier model from each provider:

These rates are approximate and change frequently. Always verify against each provider's current pricing page before budgeting.

The point isn't which model is cheapest. The point is that a customer request routed to Gemini costs a different amount than the same request routed to Anthropic, even if the input and output are identical in length. So I can't just count tokens and multiply by one rate. I need to know which provider handled each request and price it accordingly.

Different Discounts

Each provider offers ways to reduce costs, but the discounts work differently.

OpenAI gives a 90% discount on cached input (repeated prompt prefixes) and a 50% discount for batch processing, where you submit requests as a batch job and wait up to 24 hours for results. Anthropic offers nearly identical discounts: 90% on cached input, 50% on batch. Google's Gemini has four service tiers (Standard, Batch, Flex, and Priority) that change the rate for the same model by anywhere from half price to nearly double. Gemini also has a context cliff: once a single prompt exceeds 200,000 tokens, input pricing roughly doubles on Pro models.

If one customer's requests happen to qualify for cached pricing on one provider but not another, their real cost per request is different from what a simple rate table would suggest. The discount mechanics matter because they make the same nominal rate produce different actual bills.

Different Response Shapes

Even the way providers measure usage isn't identical. Some models generate internal "thinking" tokens, reasoning steps the model works through before producing its visible answer, and those thinking tokens get billed at the full output rate even though the customer never sees them. A model that returns a two-sentence answer might bill for a thousand tokens of hidden reasoning underneath.

This means two providers can process the same customer request, return roughly the same answer, and charge materially different amounts, not because the rates are different, but because the metering is different.

What to Capture to Track AI Costs Across OpenAI, Anthropic, and Gemini

If you've already read the base attribution article, this part will sound familiar. The minimum set of information you need on every AI request is the same:

• Customer ID: which customer triggered this request
• Feature: which part of your product made the request
• Model: which specific AI model handled it
• Token counts: how many tokens went in and how many came out

To unify AI costs across LLM providers, you add exactly one field:

• Provider: which AI provider (OpenAI, Anthropic, or Gemini) handled this call

That's it. The core habit is the same. You're adding one label, not building a new system. I'd tell my developer: "Every AI request already carries the customer and feature. Now add which provider handled it, so I can price it correctly."

Turning Three Bills Into One Number for One Customer

This is where a blended AI cost per customer actually gets calculated. It's a three-step process, and none of the steps are complicated individually. The challenge is doing them consistently.

Step 1 - Tag every call the same way, regardless of provider

Whether the request goes to OpenAI, Anthropic, or Gemini, the same labels travel with it: customer ID, feature, model name, and provider. This needs to be uniform. If OpenAI calls carry a customer tag but Gemini calls don't, the Gemini portion of that customer's cost becomes invisible.

This is the part I'd ask my developer to handle. The instruction is simple: "I need the same set of labels on every AI request, no matter which provider it goes to."

Step 2 - Price each call using that provider's own rate

This is where it gets genuinely tedious. Each provider publishes a rate card, the list of what each model costs per million tokens of input and output. To get the real cost of one request, you multiply the token counts from that request by the rates for the specific model and provider that handled it.

Let's say Customer A triggered two requests today:

(These numbers are illustrative.)

I can't just average the two rates. I have to price each call individually, using the correct provider's rate, because those rates are different.

Step 3 - Add it up by customer, not by provider

Once every call is individually priced, I group by customer. Customer A's total AI cost for the day is $0.0120 + $0.0278 = $0.0398. Over a month, that adds up to a real number I can compare against what Customer A pays me.

The key shift here is that I'm organizing the data by customer, not by provider. My OpenAI dashboard shows me one total. My Anthropic dashboard shows another. My Gemini console shows a third. None of them can show me Customer A's cost across all three. That rollup is the whole point of AI cost per customer across multiple providers, and it has to happen outside the provider dashboards.

The Trap: Keeping a Rate Table Current by Hand

Steps 1 through 3 are logical and not technically difficult. The real trap is Step 2, specifically keeping the rate table accurate over time.

AI provider pricing changes constantly. OpenAI has adjusted its model pricing multiple times since launching GPT-5. Gemini has four service tiers that each produce a different effective rate for the same model. Anthropic has deprecated older models whose rates were three times higher than current equivalents. Models get renamed, retired, and replaced, and the rate card changes with them.

If I'm maintaining a spreadsheet of provider rates by hand, it quietly goes stale. And stale rates produce wrong per-customer costs, which produce wrong margin numbers, which produce wrong pricing decisions. The spreadsheet doesn't warn me. It just lies.

This is honestly the part where I'd stop trying to maintain it manually. The logic of "tag, price, group" isn't hard. The maintenance of "keep three rate cards current across every model version and discount tier" is genuinely annoying, and it's exactly the kind of thing a tool should handle.

If you want to see what your current spend looks like before building anything, the free LLM Spend Analyzer can give you a baseline.

When One Feature Spans More Than One Provider

There's a scenario that makes this even messier, and it's increasingly common: a single feature, or even a single customer action, calls more than one provider in one workflow.

For example, imagine a document analysis feature. The customer uploads a long document. Your product sends it to Gemini, which handles long-context parsing well. Then it takes the extracted data and sends a follow-up request to Claude for a structured summary. One customer action, two providers, two separate costs.

If I'm only tracking at the provider level, I see a Gemini charge and an Anthropic charge. I don't see that both came from the same customer clicking one button. Connecting those costs back to one customer and one feature is what makes the margin number real.

A Worked Example: One Customer, Three Providers, One Margin Number

Here's what the full rollup looks like for one illustrative customer over a month. These are hypothetical numbers, clearly labeled; the structure is the point, not the specific figures.

Without the multi-provider rollup, I'd see three separate charges on three separate dashboards and have no way to connect them to this customer's plan revenue. With it, I can see that this customer is comfortably profitable, with a 69% AI margin, and that Anthropic is the biggest cost driver, probably because the features routed to Claude are the ones this customer uses most.

Now multiply this across my entire customer base. Some customers might be at 80% margin. Others might be at 15%. I won't know the difference unless I can produce this rollup per customer, across all providers.

If you've gotten this far, you already understand the logic. Tag, price, group, same as single-provider attribution, just with the added complexity of keeping multiple rate cards current and making sure nothing slips through the cracks.

That last part, keeping it current and complete, is where most founders either stop doing it or start living in a spreadsheet they know is slightly wrong. That's the part AI Observly is built for. Point it at your OpenAI, Anthropic, or Gemini usage, and it handles the per-customer cost attribution across all of them, including keeping the rates current so the margin numbers are actually trustworthy.

Quick Glossary

If any of the terms in this article are unfamiliar, here's a plain-language reference. I've explained each one the first time it comes up, but this is here if you need a quick reminder.

AI Provider: A company that offers AI models you can use in your product through their service. In this article, the three providers are OpenAI (which makes the GPT models), Anthropic (which makes Claude), and Google (which makes Gemini).

API Request (or API Call): Every time your product asks an AI provider to do something, generate a response, summarize a document, answer a question, that's an API request. Think of it as your software placing an order with the AI provider. Each request gets billed.

Attribution: The practice of connecting a cost back to whatever caused it. In this article, "per-customer cost attribution" means figuring out which customer was responsible for each AI cost, so you can see how much each customer costs you to serve.

Batch Processing: A way to submit AI requests in bulk and let the provider process them on its own schedule, usually within 24 hours. It's slower than real-time, but providers typically charge about half the normal rate for batch work. Useful for tasks that don't need an instant response, like processing data overnight.

Blended Cost: The combined total cost of serving one customer across all AI providers, added together into a single number. "Blended" because it mixes costs from providers with different rates into one figure you can compare against revenue.

Cached Input (Prompt Caching): When your product sends the same instructions to an AI model repeatedly (like a system prompt that stays the same across every request), providers can recognize the repeated part and charge a heavily discounted rate for it: often 90% less. It's like a store giving you a discount because you keep ordering the same thing.

Context (Context Window): The total amount of text an AI model can process in a single request. Think of it as the model's working memory. Most modern models can handle very long inputs, hundreds of thousands of tokens, but some providers charge more once you exceed a certain threshold (see "Context Cliff").

Context Cliff: A pricing jump that happens when a single request exceeds a certain size. For example, Google's Gemini Pro models roughly double their input rate once a prompt crosses 200,000 tokens. The rate doesn't gradually increase, it steps up at a threshold, like a cliff.

Customer ID: A unique label your software uses to identify which customer triggered a request. It could be a name, a number, or any tag, the point is that it travels with the AI request so you can trace the cost back to the right customer.

Dashboard: A visual display, usually inside the AI provider's website, that shows your usage and spending. Each provider has its own dashboard. The problem this article addresses is that no single provider's dashboard can show you a customer's cost across all providers, it only shows what happened on its own platform.

Deprecated (Deprecation): When a provider retires an older AI model and replaces it with a newer one. The old model stops working after a certain date. This matters for cost tracking because the old and new models often have different rates, and a rate table built for the old model becomes inaccurate.

Input Tokens: The tokens your product sends to the AI model, the question, the document, the instructions. This is the "reading" side of the bill. Providers charge separately for input and output, usually at different rates.

LLM (Large Language Model): The type of AI model that powers text-based AI features in most SaaS products. GPT, Claude, and Gemini are all LLMs. When this article says "LLM costs," it means the cost of using these models through their providers' services.

Margin (AI Margin): The money left over after subtracting AI costs from what the customer pays you. If a customer pays $49/month and their AI usage costs you $15, your AI margin on that customer is $34 (about 69%). This is the number that tells you whether a customer is actually profitable after AI costs.

Metering: How a provider measures and counts your usage for billing purposes. Different providers meter differently, some count hidden "thinking" tokens as billable output, others don't. This means two providers can process the same request and report different usage numbers.

Model: A specific AI product offered by a provider. For example, OpenAI offers GPT-5.4 and GPT-5.5, which are different models with different capabilities and prices. Anthropic offers Claude Sonnet and Claude Opus. "Model" is the specific version you're using, not just the provider.

Output Tokens: The tokens the AI model generates as its response, the answer, the summary, the content. This is the "writing" side of the bill. Output tokens are almost always more expensive than input tokens, sometimes four to eight times more.

Rate Card: The list of prices a provider charges for each model. It tells you the cost per million input tokens and per million output tokens for every model they offer. Rate cards change when providers adjust pricing, launch new models, or retire old ones.

Rollup: Adding up individual costs into a total. In this article, "rollup" means combining a customer's costs from each provider into one combined number, grouped by customer rather than by provider.

Service Tiers: Pricing levels offered by a provider for the same model. Google Gemini, for example, has Standard, Batch, Flex, and Priority tiers, each with different pricing and speed trade-offs. The same model can cost half as much on the Batch tier or nearly double on the Priority tier.

Tagging: The practice of attaching labels (like customer ID, feature name, and provider) to every AI request so you can trace each cost back to its source. It's the foundation of cost attribution.

Thinking Tokens: Internal reasoning steps that some AI models generate before producing their visible answer. The customer never sees them, but they get billed at the full output token rate. A short visible answer can have a large invisible thinking cost underneath it.

Token: A small chunk of text that AI providers use to measure usage and calculate your bill. Roughly speaking, one token is about three-quarters of an English word. Providers charge per million tokens, separately for input (what you send) and output (what the model generates).